Paul TBBle Hampson wrote: > On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote: > >>Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: >> >>>Maybe the one-true-stable-key idea is the way to go after all... > > >>One key by distribution? > > > Well, I meant a different one for each stable, which I guess logically > becomes "yes"... > > Although as Steve Langasek has pointed out, the Sarge->Etch upgrade will > be hard unless the etch key becomes available to Sarge users who've not > touched their system since Sarge r0a... I guess this comes down to > making the etch key available in some kind of Sarge-signed repository, > that you have to add as part of the Etch upgrade, and after which > apt-key update will bring you up to Etch key currentness. > > Assuming apt-key is supposed to be updating from a file in > debian-keyring, maybe a new dist ("oldstable-upgrade") which really only > contains debian-keyring from (new)stable, but which is signed with the > oldstable key. Then the online upgrade procedure becomes: > > Add oldstable-upgrade to your apt-sources > apt-get update > apt-get install -t oldstable-upgrade debian-keyring > apt-key update > apt-get update <== To recheck signatures... I dunno if this is needed? > apt-get dist-upgrade > ... time passes > echo "Welcome to etch!" > > (Or maybe using aptitude, if that's the recommended upgrade method for > Etch as well...) > > I dunno exactly how apt-cdrom works, but maybe it could automatically > pick up that an etch CD has both oldstable-upgrade and stable dists, and > therefore the process for CD upgrades becomes: > > apt-cdrom > apt-get install -t oldstable-upgrade debian-keyring > apt-key update > apt-get update <== To recheck signatures... I dunno if this is needed? > apt-get dist-upgrade > ... time passes > echo "Welcome to etch!" > > You'll still get complaints during apt-get update the first time, but > the apt-get install at least won't try to reject debian-keyring for > being unsigned, because _it_ is signed with a known signature. > > For the intervening time, security updates and rX releases thereof allow > for stable key rollover as needed, either yearly or when compromised. > > This way oldstable-upgrade gets rolled-away with the rest of oldstable, > and isn't part of oldstable per se and so doesn't complicate security > updates or whatnot, and is easy to include on the first CD of the new > release for upgraders. > > And the (new) stable key is therefore (transitively) signed with the > oldstable key, maintaining the chain of trust, without actually having > to muck about with gpg signatures.
Consider the following keys: * sarge key (expires after the date we expect to release etch +1) * etch key (expires after the date we expect to release etch +2) * etch+1 key (likewise for etch +3) * 2005 testing/unstable key (expires at the end of 2006) * 2006 testing/unstable key (expires at the end of 2007) * 2007 testing/unstable key (expires at the end of 2008) The following distributions should be signed as follows on the following dates: etch in 2006: sarge key, etch key, 2005 key, 2006 key etch in 2007: sarge key, etch key, 2006 key, 2007 key testing/unstable in 2006: 2005 key, 2006 key testing/unstable in 2007: 2006 key, 2007 key -- I usually have a GPG digital signature included as an attachment. See http://www.gnupg.org/ for info about these digital signatures. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]