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

[Daniel Kahn Gillmor]

On 09/22/2014 04:06 PM, Hans-Christoph Steiner wrote:
> I think we're starting to nail down the moving parts here, so I want to
> outline that so we can find out the parts where we agree and where we disagree.
> 
> * I hope we can all agree that the package itself should not change once it
> has hit the official repos.
> 
> * I believe we can achieve what we want without taking a shortcut and
> introducing a new core package type (.sdeb .debs or whatever).  We can figure
> out how to do this with the .deb file.  Personally, I would accept a new
> package type after a thorough exploration of keeping .deb fails to deliver,
> but not before.
> 
> * There should be at least one verification build before a package becomes
> official.
> 
> * Then there needs to be a channel for people to submit the results of their
> own builds.  That could be only positive results or only negative results, or
> both.
> 
> * the .buildinfo file should contain all info needed to reproduce the build,
> given a standard Debian build environment

Thanks, the above is a very useful summary.

> Anything I left out?

I think the summary above hints at but doesn't answer the question of
what an "official" package means, and the fact that there may be
multiple repositories (possibly operated by different organizations)
with different rules about what should make a package "official".

I think we need to ask whether we care about byte-for-byte identical
.deb files *across* different repositories or not.

If we don't care about cross-repo (or cross-organization) byte-for-byte
reproducibility, then an embedded signature in the .deb might be
acceptable (though the data it contains would be redundant to signatures
over the buildinfo files, which would eventually be necessary for
external policies or corroboration anyway).

If we *do* decide that we care about cross-repo byte-for-byte
compatibility, then embedding a signature in the .deb suggests that one
repo can act as the gating factor for another, because repos
collaborating in this reproducibility push cannot both hold the key that
makes a .deb "official".

I don't think that's a good tradeoff.  As tempting as it might be to try
to cement debian's "authoritative" role via such a lock-in, i'd much
rather than debian derivatives, blends, side projects, etc, can all take
initiative that can then be absorbed back into debian cleanly and
reproducibly.

i also suspect that the redundancy between internal signatures and
signed .buildinfo records is likely to cause some increase in confusion,
but i don't think that's as serious of a problem as the question of
which signing keys get to be "authoritative".

	--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/20140922/c5b10151/attachment.sig>