Re: bits from the release team
Pierre Habouzit <email@example.com> writes:
> Le Ven 5 Mai 2006 18:41, Florian Weimer a Ã©crit :
>> * Lionel Elie Mamane:
>> > Why can't we have a master key that signs the yearly keys? After
>> > all, we have a long-term unique X.509 master key, so what's the
>> > difference with OpenPGP?
>> End users are typically not exposed to the X.509 keys, which makes
>> things a lot easier.
>> By the way, if you've got a master key, you need to plan for key
>> rollover, too. Why not apply that procedure directly to the keys
>> used to sign the release files? A yearly key change just results in
>> unnecessary administrative overhead for our users, without providing
>> any real benefit to them. A key compromise still needs manual
>> At the very least, if we have to keep that yearly key change for
>> political reasons, please schedule it in a way that it doesn't happen
>> in January.
> Proposal 1:
> a possible way would be to have two valid keys at any time. like one
> new key per year (or 6 month like you want) with a validity of 2 years
> (resp. one year).
> that would obviously mean two signatures per package (but I don't
> think that's that much work) and would require the user to update
> their "keyring package" only once every year (or 6 month), which looks
> like a quite reasonnable trade-off. Even stable updates can use that
> scheme, since it's released more than once a year.
Except that apt-get fails if any of the signatures are unknown or
expired. So you still need both keys and not just one of them as you
> Proposal 2:
> the package that holds the public signature key has to contain every
> single emited key, and be signed with any anterior one. Meaning that
> the upgrade for any user would be smooth.
> I don't think that having a kludge in dpkg that forces the upgrade of
> that package ASAP would be hard or dangerous to implement, so that
> even a non aware user could just "apt-get update" without having read
> the release notes.
> This is simpler, but less secure than the Proposal 1.
Not applicable to non debian repositories or easily exploitable to
work on any package.
> Proposal ...:
> there is a lot of such ideas IMHO, one just has to think 10 minutes to
> imagine a couple of ones.
> IMHO, changing the key every year at any date is not problematic at all,
> because there is plenty of solution to do smooth replacement of the
Do you see any drawbacks with my proposal of having Release.key next
to each Releas.gpg or do you have a better idea that will work for
every apt-getable archive?