Re: apt in experimental (Re: APT 0.6 migration -- second status report)
Matt Zimmerman <email@example.com> writes:
> On Wed, May 04, 2005 at 11:51:21PM +0200, Goswin von Brederlow wrote:
>> Matt Zimmerman <firstname.lastname@example.org> writes:
>> > In mainline, there is a facility for adding new keys to the keyring by
>> > updating the apt package.
>> Which can't be done (savely) if the key is compromised or expires
>> before the update (like it does every year).
> If the key is compromised, we lose, no matter what we do.
> I recommend that we create keys which will not expire before the next
> - mdz
How about this:
Each distribution key gets signed by X+Y DDs in the current (stable)
keyring. On key updates the new key is checked and if X of those
signatures are still valid and the key is newer than the existing one
then the key is accepted as new key.
Keeping X reasonably large ensures that a compromised key (or two or
three) can't be used to smuggle in an fake archive key.
Keeping Y large ensures a new key can still be checked and accepted.
The timestamp of the key and signatures should be checked to prevent
undoing a key update by rolling in an old, compromised key.
All of this should be wrapped in something like "apt-get update-keys" and
mentioned in the error message when Release.gpg fails the check.
Or, even better, have apt-get update download a Release.keys and
verify through the above procedure automatically.