Re: Secure APT Key Management
Andreas Barth wrote:
> Hi,
>
> I try to summarize the results of the discussion from start of August,
> in hope that we can finish this off, and test-run this first for the
> next stable point release. From the security team, some input on their
> preference would be welcome.
>
>
> The idea is to have different keys:
> - One standard online-key for signing unstable; this key would be
> rotated e.g. yearly (or whatever the ftp-masters consider fit, I don't
> really mind).
> - One release key per stable release; taken care offline by the stable
> release team.
> - One security key per stable release; taken care somehow by the
> security team.
Umh... you know that currently the security team has no authority
over the use of any gpg key during the release of security updates,
right? So, this seems to require modifications in the archive
software (and there are several issues pending for years already).
The same most probably applies to the SRM key/team.
> Apt in stable recognizes as valid:
> - The current stable key
> - The previous stable key
> - The unstable key
How do you propose the key rollover with the unstable key to be
recognised by the stable apt?
> Stable Releases is signed off by:
> - The current stable key
> - The previous stable key
> - The unstable key (perhaps also by the previous/next near to a
> rollover)
>
> Security Releases is signed off by:
Out of curiosity, what is a Security Release? Every security update?
> - The current security key
> - The previous security key
Why not the current stable security key?
(and the previous stable security key, you've introduced them above
at least).
I'm not sure what a different security key buys us except another
set of keys to handle, especially when the key is only known to
the dak operator and the dak software.
> - The unstable key (perhaps also by the previous/next near to a
> rollover)
>
> Stable release keys (and perhaps also security keys, depending on the
> security team) don't have expiry dates, but are expired with publishing
> a revocation certificate with stable+2 (as we still need the key for
> stable+1 for upgrades).
When there are stable security keys, they should have an expiration
date set (high enough so that Debian has enough chances to update
their distribution as releases in the meantime).
When there is only one security key, it's not clear to me what
an expiration buys us. A way is required to get new key to the
user in case of a compromise and to revoke the old one.
> So, if someone upgrades e.g. from sarge to etch (just using them as
> names now, ignoring that sarge doesn't contain such an apt):
>
> Client runs sarge - authoritative are woody, sarge, expired old sid key
... when the key is expired, it's not useful anymore, hardly
considered as authoritative...
> Client gets etch-Release.gpg from mirror (signed off by sarge, etch, sid)
.... new sid key
> Client verifies etch-Release.gpg with sarge key
> Client installs new packages - now authoritative sarge, etch, sid keys
> (and installation contained a revokation for the woody key).
How? Where?
Regards,
Joey
--
Linux - the choice of a GNU generation.
Reply to: