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

[Hans-Christoph Steiner]

Daniel Kahn Gillmor wrote:
> On 09/19/2014 12:34 AM, Paul Wise wrote:
>> On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote:
>>
>>> Finally did this:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153
>>
>> Please note that you proposal to add signatures to .deb files will
>> break reproducible builds because the hash of the .deb will differ
>> depending on who signed it:
>>
>> https://wiki.debian.org/ReproducibleBuilds
>>
>> I think it would be far better to ship detached signatures in the
>> archive since that allows for reproducible builds and also means there
>> could be more than one signer (say one buildd, one Debian sponsor and
>> one package maintainer).
> 
> I agree with pabs on this.
> 
> fwiw, i'm also hoping that we can ship at least one other signature for
> the upstream tarball (where such a thing exists):
> 
>  https://bugs.debian.org/759478
> 
> We also had a discussion in the reproducible-builds BoF at DC14 about
> how to deal with signatures on .buildinfo files, and came to the same
> conclusion: that a .buildinfo file should have detached signatures, to
> allow for multiple (corroborative) signers:
> 
>  https://wiki.debian.org/ReproducibleBuilds#A.buildinfo_signatures
> 
> Note that a signature over a .buildinfo file should effectively cover
> the digest of the built .deb files, which should creates a strong
> cryptographic chain if you trust the hash function.
> 
> Given that we would ultimately like one or more signed .buildinfo files
> shipped in the archive, and that they represent a way to have an
> builder's signature over a .deb, i think these make the idea of an
> internally-signed .deb redundant.
> 
> Thanks to everyone who is thinking about and working on improving the
> cryptographic integrity of the archive!
> 
> 	--dkg

Having the signature in the .deb file does not necessarily break
reproducibility and it does produce a signature that is vastly easier to use
than a detached file because if you have the file, you have the signature (see
my offline TAILS example).  First there needs to be a source of a canonical
embedded signature, then that signature just needs to be copied into the
package on each build.  Since everything else is exactly the same, copying the
signature works.  That canonical signature could be from dak, from the
maintainer, or perhaps elsewhere.

There are many widespread precedents for including the signature in the
package itself: .jar, .apk, .rpm, Windows packages, etc.  The code for an
embedded signature is more complicated than a detached signature, so there is
more risk to that approach (for example, Android's Master Key bug).  Since apt
already provides a detached signature, I think the risk in Debian is much
lower and usability gain is much larger so its a worthwhile trade-off.

.hc

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