[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt 0.6 in experimental



On Sat, 27 Dec 2003 23:50:01 -0800
Matt Zimmerman <mdz@debian.org> wrote:
> > > That key is also still used to sign stable, stable/non-US and
> > > proposed-updates/non-US, though proposed-updates is signed with the new v2
> > > key.
> > 
> > I was actually going to ask - what happens to stable users when either a
> > release takes longer than a year to get out, or they want to skip a stable
> > version and go for the one after?
> 
> I don't see the problem...they just need to grab the new key and feed it to
> apt-key.  The keyring provided by default is just a convenience for the
> common case; normally you need to take care of importing the keys yourself.

Ah, hm. I was thinking it would be a bit of a pain for people to have to
do so every year or whatever.

> > Perhaps an archive signing key for each dist, instead of one for each
> > year? Several of each should probably be generated, too, and all but the
> > live one kept offline in different locations, in case of compromise.
> 
> Do I understand that you are suggesting we pre-generate keys for future use,
> so that we can include them with the current distribution?

(If you don't mind a side-bar, is that sort of thing evil and/or bad?)

That's only part of it, but yes. Say three keys for each dist (Woody,
Sarge, and Sid), for a total of nine. My basic assumption here is that
keyring maintenance would be an unpleasant thing for an end-user to have
to do. This may be a bad assumption. That being said, the scenarios I
was envisioning were:

1) Sarge releases in 2004 with a single key in the keyring ("Debian
   Archive Automatic Signing Key (2004)"), and either an update to Sarge
   or a Sarge+1 gets uploaded in 2005 or later:
   - The admin will need to manually import the 2005 key, or override
     apt's warnings, because Release will be signed with the 2005 key
     but it's not in their keyring

2) Archive key is compromised, user only has the one key in their
   keyring:
   - As above, except that if they don't know there's been a compromise,
     they'll probably freak out because it's not the end of the year and
     things appear to be signed with a different key.

I'm not sure if having the admin do key maintenance is a bad thing. From
an ease-of-use perspective, it would obviously be good to have things be
done in an uninterrupted manner so that the only notice they get is when
something's seriously wrong.

On the other hand, if they're properly educated and thorough, obviously
it would be better to let them judge new keys by their own standards.

I think I would err on the side of "do things without user intervention"
because it's easy for somebody to do their own keyring maintenance.



Reply to: