[Reproducible-builds] Preliminary review of dpkg-genbuildinfo

[Daniel Kahn Gillmor]

On Mon 2015-02-16 04:39:32 -0500, Hans-Christoph Steiner wrote:
> 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

The above bullet points don't seem mutually compatible.  if the uploader
is doing the per-package signing, then their key won't be in the apt
keyring; this would make each package have a bad sig; and would mean
that dpkg in signature-checking mode would reject the packages.

Choosing the apt keyring as the signing model appears to punt entirely
on questions of corroborative authority and how that plays out in a
multi-distro ecosystem.

But overall, I think this discussion of embedded per-package signatures
misses the point: the only reason we're talking about possible future
per-package signatures is because we want to avoid breaking them as we
add mechanisms to support reproducible builds.

We *have* a team actively working on reproducible builds (this mailing
list), who have done a lot of work already and have thought about the
needs for that project.

If we don't have a use case or a plan or a team or a goal or known
constraints for doing embedded per-package signing, then delaying the
archive and system changes needed by reproducible builds on behalf of
some non-concrete desire for per-package signatures is a mistake.  We
shouldn't be blocking progress on an active and effective project for
one that isn't underway at all.

And remember that we already have a very clear understanding of how to
do *non-embedded* per-package signatures, should anyone want to do them.

My pkg-fingerprint proposal was trying to lay out compromise that would
leave per-package embedded signatures possible in the future without
having to specify them in detail today.  I don't *want* to specify them
in detail today.  I want to be able to move on with making the archive
reproducible :)

             --dkg