Re: Summary: Secure APT Key Management
Anthony Towns <aj@azure.humbug.org.au> writes:
> Joey: Thanks for the Bcc.
>
> On Sun, Jul 30, 2006 at 12:56:26PM +0200, Martin Schulze wrote:
>> 5. http://lists.debian.org/debian-release/2006/07/msg00202.html
>> Rapha?l Hertzog suggested[2] to use two signatures, one from a yearly
>> key and one from a stable release key.
>
> From the discussion previously, it seemed that the way keys would be updated
> usually was by:
>
> (1) someone has a working system
> (2) they apt-get update, verified by key N
Which fails due to:
- key roll over was already, user uypgrades too late
- key expired, as has happened on every roll over so far
- key compromised, unscheduled roll over
> (3) they apt-get dist-upgrade to a new apt, which automatically sets
> key N+1 as a trusted key
This then means accepting the new key without any trust.
> (4) apt-get update, verified by key N+1
>
> That means there needs to be an overlap between when the new key is added
> to the distro (both for propogation to testing and included in a stable
> point release) and the old key is used for signing packages.
>
> So having a "release" key would be something like:
>
> * create a new key now that will work for etch's lifetime
> (assuming etch+1 releases 18 months after etch in July 2008,
> and gets security support for a further 12 months, that's from
> 2006-12-01 -> 2009-06-30)
>
> * (if necessary releasing a new etch key if etch+1 hasn't been released
> and etch's key is set to expire during the next point release)
>
> * creating a new key for etch+1's lifetime prior to it's release
> by at least one point release of etch, that will last for as long
> as etch+1's expected lifetime
>
> And having an annual key would be something like:
>
> * including the 2006 key in apt in all suites (sarge, etch, unstable)
>
> * creating the 2007 key in time to be included in the last sarge
> point release in 2006, and first etch release in 2006
>
> * creating the 2008 key in time to be included in the last etch
> point release in 2007, and to propogate through to testing before
> 2008, etc
>
> * repeat...
Plus several backup keys in case a unscheduled roll over has to be
done. You also need keys for stable, testing/unstable/experimental,
security, backports, snapshot.d.n, and all the inofficial archives out
there that also want to sign Release files. Managing all the
(semi)official keys well in advance will be near impossible and Debian
hasn't even managed to do a single key roll over on time yet, let
alone well in advance.
Past records indicate that this will be impossible. Any good key
handling HAS to plan for screwups. For me that means new keys must be
validated against the web of trust and not any short lived special
key, at leats optionaly. Updating the key contained in the apt.deb is
a nice idea but will surely fail at some point.
> Cheers,
> aj
MfG
Goswin
Reply to: