[Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Daniel Kahn Gillmor]

Thanks for the discussion, Hans.

On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
> Packages should not be accepted into any official repo, sid included, without
> some verification builds.  A .deb should remain unchanged once it is accepted
> into any official repo (maybe experimental could be an exception, but not
> sid).  I think that is essential.

But some repositories could have different rules for package inclusion
than others, right?  for example, say debian wanted to offer an
unstable-reproducible suite, which only permitted packages that had been
independently rebuilt reproducibly by multiple DDs and at least two
different buildds.  Ideally, the packages that are shared between this
repository and other repositories would be identical.

Note that if .deb files are internally signed, two developers *cannot*
create the same exact .deb if they do not share their secret keys.

> I see no reason for changing the .deb between sid and testing, except for
> perhaps how existing implementations are doing it.  It is usually worth the
> work to do things right way, rather than the easy way.

I agree with this sentiment, i think we're trying to sort out what is
the "right way".

> The build verification process needs to happen between the package upload and
> publishing to sid or security updates.  Two builds is easy: the .deb that the
> uploader generates and the one the Debian process makes.  That is probably enough.
> 
> In Debian's case, it probably is too complicated to include multiple
> signatures.  In that case, there should be only one canonical signature by dak
> once the build verification signature threshold has been passed. Then all of
> the other signatures could be added to .buildinfo or .changes or whatever
> other file.

but the .buildinfo file is designed to say "i generated the .deb that
matches this digest exactly", which the corroborating builder cannot do,
because they cannot produce the internal signature.

Plus, we now have two different places to look for signatures.  one
"canonical" one and then some external ones, and the signatures
themselves have different properties (one signs parts of the deb, the
other signs the whole .deb; one signs the build environment, the other
does not, etc)

> Another option is to do it like f-droid.org does.  F-droid.org generates a APK
> signing key for each app, then manages the signing on a specialized signing
> server.  Or another option is just requiring all the signers to be from the
> debian-keyring, rather than an exact match for previous signers.

Again, i think this is getting ahead of the discussion.  i'm not
proposing that we try to set debian (or other derived distro) archive
policy here, i just think we want to think

>  In any case, the .deb needs to remain unchanged.

right.  but it can't be unchanged if the archive distributor decides
that a different signer is the "canonical" signer.  So you're making the
contents of the .deb dependent on archive policy, rather than the other
way around.

I *want* ubuntu and debian and mint to all ship the exact same .deb for
any packages that are reproducible (and eventually, all packages!) that
they share, and i also want those different distros to be able to
produce the reproducible .deb independently of one another.  If
foo_1.2-3_mipsel.deb is built first on the ubuntu builders and ubuntu
decides to include it in the archive, and then debian is able to
reproduce that build and wants to include it in debian, these should be
the same .deb file, even though the archive gating infrastructure is
independent.

> I think this can be done using the existing .deb format.  This.debs approach
> also requires a conscious opt-in: "we tell users and upstream developers that
> if they want to install packages via sneakernet..."

exactly, and i think this is a good thing.  it's a clear external signal
that they're transporting a signed object.  Users can also sneakernet
around arbitrary .tgz files, or .zip files, or .dmg's or whatever.  we
can't stop them from doing that, but we *can* say "if you want to
sneakernet things around with any sort of cryptographic security, you
should be sneakernetting things that look like *.debs, and nothing else".

If we say "some .deb files might be signed, some might not, good luck
with that" it's less clear.

There is a long-standing, widely understood idea about what a .deb is.
Changing that to be something that only a given party can generate goes
directly against the goal of having builds be reproducible.

We know that detached signatures allow us the flexibility to do all
kinds of clever archive-decided policy while sharing a broad consensus
about the byte-for-byte nature of any piece of compiled code.

Detached signatures fail at ease of manual transport.

Introducing a package wrapper that includes signatures to facilitate
manual transport seems like the way to solve that problem, rather than
having to embed or privilege any one canonical signature above another,
or introduce two different-yet-similar mechanisms for individual binary
package signing and verification.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20140919/8e0d9750/attachment.sig>