Re: APT public key updates?
Paul TBBle Hampson wrote:
> On Sat, Jan 07, 2006 at 12:16:36PM +0100, Bernd Eckenfels wrote:
>
>>Paul TBBle Hampson <Paul.Hampson@anu.edu.au> 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.
Reply to: