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

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.

.hc


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

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to