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
>> 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
>> 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 :)
I cannot imagine an development effort in the reasonable future that would
actually achieve some kind of multiple signature tricks for embedded sigs. I
think the only reasonable thing to consider is a single canonical embedded
signature, because that is something that can actually be implemented,
technically, time-wise, and politics-wise. It is also something that is
widely implemented in other systems, like Android. Its a tried-n-true idea.
And a single-canonical embedded signature is actually not hard when it comes
to building reproducibly.
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
Reproducible-builds mailing list