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

[Hans-Christoph Steiner]

Daniel Kahn Gillmor wrote:
> 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

Cross-repo byte-for-byte compatibility is a nice thing to strive for, but it
sounds quite difficult to achieve and will require lots of social coordination
as well as technical work.

In terms of builds of a particular .deb by multiple distros, each distro will
have to use the exact same toolchain to build the .deb for most packages.
Different versions of gcc, javac, etc. will produce different binaries.
You'll have the same problems as the canonical signature, like if two distros
make a new package at the same time, but with different standards (gcc
version, signer, etc).  Ubuntu's gcc version will create a .deb with one hash,
and Debian's gcc will create a .deb with a different hash, and each distro
will mark theirs as canonical. That seems to be a much harder thing to manage
across the distros.  So if another distro or repo is going to buy into
Debian's reproducible system, adding a bit about canonical signatures seems
totally feasible to manage.

The canonical signature would just need to be done by a key in the
debian-keyring for Debian, ubuntu-keyring for Ubuntu, etc.  While a static
canonical signer is desirable, I don't think it can be supported without
adding some restrictions (I think it would be worth it, for the record).

Whoever is the first to publish a given package version claims the canonical
role for both build setup and signature.  To prevent accidental collisions,
dput could check the various NEW queues, the various package repos, etc. to
look for an existing canonical package.  Then the first distro to publish is
canonical.

Shall we have a real time discussion on this topic? voice, video, or in person
all work for me.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81