[Reproducible-builds] Preliminary review of dpkg-genbuildinfo

[Hans-Christoph Steiner]

Daniel Kahn Gillmor:
> On Fri 2015-02-06 01:13:18 -0500, Guillem Jover wrote:
>> Take the example I gave previously of a binary package detached from
>> an archive, just a .deb package laying around, either from an old
>> download or passed to you by someone. You have to *know* the origin of
>> the binary, otherwise you need to first start hunting down where this
>> binary was built, say Debian, one of its derivatives or even somewhere
>> else. And sure, once that's known, the user *might* possibly be able to
>> reproduce the build, but I don't see many (if not most) users being able
>> or willing to set up a reproducible build environment just to verify
>> where a binary was coming from (say my relatives). If you cannot or
>> wont do that, you need to trust the distribution, the remote server,
>> the network, the remote binary including any possible reproducible
>> information being correct. At that point you or a program might as well
>> have just verified an embedded signature.
> 
> I see per-package signatures and reproducible builds as complementary to
> one another.  I'd be happy to brainstorm ways that we can make sure we
> can get the advantages of both.
> 
> I understand the goals of per-package signatures, and that it's more
> convenient for most folks to have a single file than to have to schlep
> around multiple files to be able to verify the package.
> 
> I also understand the ecological benefits of reproducibility, especially
> for a project like debian that has so many heterogenous downstreams that
> pull (directly or indirectly) from it.
> 
> For one of the big reproducibility benefits -- detecting compromised
> build environments -- to accrue to everyone, we only need a handful of
> independent reproducers who can't all be compromised together, and a
> straightforward way that people can compare the results and raise an
> alarm if something looks fishy.
> 
> The benefits of reproducibility come from *corroboration*.  otoh, the
> usual view of embedded package signatures come from *single authority*
> ("the origin of the binary").  For the broader ecosystem of debian + its
> derivatives, where some binary packages might be shipped by multiple
> vendors, it is actually useful to users of a derivative that doesn't
> rebuild everything to be able to say with confidence "this package is
> exactly the same as the packages debian ships".  At the same time, as a
> user of the derivative, you'd also like to be able to know that any
> given package is "endorsed" or included by your distro, so that
> arbitrary packages from debian proper can't just be slipped by your
> package manager without knowing about it.
> 
> So there's this interplay (tension?) between authority of origin and
> corroboration that i suspect we'd all like to support.
> 
> I've been partial to the separate .buildinfo file specifically because i
> think i can see the path where we can get both corroboration and
> specific authority from it (a single .buildinfo file can be signed by
> multiple authorities), while the identical .deb in two distros can be
> bitwise-compared using simple tools.
> 
> That said, this clearly doesn't address the convenience/portability
> win of embedded package signatures raised by Guillem.
> 
> As a step toward brainstorming, here's a way that we could (maybe?) get
> both:
> 
>  * we could make a pkg-fingerprint tool that takes a package and
>    produces a cryptographically-strong fingerprint of the contents of
>    the package *minus* the signature elements.
> 
>    As long as the package format has no internal signature, this would
>    just be something like sha512sum over the entire package.  When we
>    have a package with an embedded-signature format, we'd need to define
>    a way to strip any/all signatures from the package in a reproducible
>    way that does not touch the rest of the contents of the package.
>    then pkg-fingerprint becomes something like:
> 
>      pkg-strip-sigs < foo.deb | sha512sum
> 
>    and the comparison between packages moves from /usr/bin/cmp to
>    comparing the outputs of pkg-fingerprint (or we could make a pkg-cmp
>    tool).
> 
>    the buildinfo files would then store the pkg-fingerprint output over
>    the .deb or .rpm binaries that they produced.
> 
> This is a little bit inelegant, but maybe it's a way that we can have
> our cake and eat it too?  I'd love to hear other suggestions.
> 
>     --dkg

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. 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

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.

I think the .buildinfo file is useful, but for a separate process.  It should
be the canonical file for running a reproducible build.

.hc

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