Re: bits from the release team
On Wed, May 10, 2006 at 11:05:03AM +0200, Goswin von Brederlow wrote:
> Pierre Habouzit <email@example.com> writes:
> > Le Ven 5 Mai 2006 18:41, Florian Weimer a Ã©crit :
> Except that apt-get fails if any of the signatures are unknown or
> expired. So you still need both keys and not just one of them as you
This was fixed in January IIRC.
> > IMHO, changing the key every year at any date is not problematic at all,
> > because there is plenty of solution to do smooth replacement of the
> > key.
> Do you see any drawbacks with my proposal of having Release.key next
> to each Releas.gpg or do you have a better idea that will work for
> every apt-getable archive?
If we do this, we must make sure that Relesae.key is properly
authenticated. The authentication of the debian-archive-keyring
package is the same as for any other package, we have a signed Release
file for it with valid md5sums. I like the general idea of this and
would like to combine it with the idea of having a master-key.
I think that the debian-archive-keyring solve the problem of
key-rollover more or less. But it does not solve the problem of
key-compromises. The archive key is then invalid and we can't sign a
new debian-archive-keyring package with it.
A possible solution for this problem is a master key that is only used
to issue new signing keys and is otherwise stored offline/off-site
(and maybe split). A "apt-key update" would download a new keyring
from a fixed location (maybe next to the Release file as Goswin
suggested) and check if the new keys are signed with the master
key. If so, the key is considered trusted.
What do the others think about this?
It shouldn't be very hard to implement, we can just ship the new
master public-key in the debian-archive-keyring package (or just put
it straight into apt).
The problem here is of course what to do if the master key is
compromised :) But the trust chain has to start somewhere and the
master key would only be used once a year to issue new signing keys
and that will expose it much less than our current signing key.
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo