[Reproducible-builds] Preliminary review of dpkg-genbuildinfo

[Hans-Christoph Steiner]

Daniel Kahn Gillmor:
> On Fri 2015-02-13 03:36:20 -0500, Hans-Christoph Steiner wrote:
>> I think it would be much simpler to just have the single package signature
>> that is embedded in the package file itself, like Android APKs and Java JARs.
>>  Since the package is built reproducibly, anyone who builds it can just copy
>> the canonical signature into their copy of the package they just built, and
>> it'll match the sha512sum of the signed apt metadata.
> 
> It seems like you're saying everyone will be able to agree on which
> signing authority is "canonical" for any given package.  I'm not
> convinced that's the case.
> 
>> The big question there is determining the where the canonical
>> signature happens.  It seems like it should be the official Debian
>> build process, since it is the only process guaranteed to be the same
> 
> Even though i'm personally likely to treat Debian as "the canonical
> source" i care about, i don't want it to be that way.  I would like
> Debian to be able to be a downstream as well as an upstream (see the
> work feeding back into debian from ubuntu, for example); if a .deb
> package can contain an internal signature, and i'm looking at a given
> .deb in isolation on my debian system, i want to see it signed *by
> debian*, not by whoever happened to produce it first.  Otherwise, it's
> not clear to me that the embedded signature is useful to me as an end
> user at all.
> 
>> Another question is whether dpkg checks whether the signers match when
>> upgrading, like the Android model (a package can only be upgraded by
>> another package signed by the same key).  This would be nice, but
>> seems optional and hard to do in Debian.
> 
> Maybe this is the question we need to answer to move the discussion
> forward to make sure we're taking the desire for embedded signatures
> into account when thinking about reproducible .debs: how exactly do we
> expect an embedded signature to be used/evaluated?  by who, and in what
> context?
>
>> I think the .buildinfo file is useful, but for a separate process.  It should
>> be the canonical file for running a reproducible build.
> 
> I'm not sure what this means.  I'd be very happy if *all* of my debian
> packages were reproducible builds, and i could have a way of verifying
> it.  I'd consider that more valuable than knowing that all my .debs were
> signed by any individual authority.  So if we're really talking about a
> tradeoff between signed buildinfo files and signed packages, i'd
> certainly prefer signed buildinfo files.
> 
> But my proposal was an attempt to let people have both, without forcing
> the entire ecosystem to agree on "who is a canonical authority for
> package X, without whom a reproducible package is impossible"
> 
>           --dkg

I think this topic is far too vast with far too many dependencies to really
have a useful discussion on without a full time, dedicated team.  Since that
seems highly unlikely in the near future, we need to break it down into chunks
of work that we can achieve with the time and resources we actually have.

So we need to focus on drilling down to what is the simplest useful form of
package signing that will cause the least amount of problems when we decide to
change how package signing works.  This means we get a prototype out as soon
as possible, and we can learn a lot from that. I think that's pretty easy to
do, something like this:

* make dpkg optionally check package sigs, and refuse to install on bad sig
* use apt signing model: signatures verified from the apt key ring
* signing can start happening in the build tools, by the uploader
* start work towards getting the Debian built/apt infrastructure signing

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81