Re: bits from the release team

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Pierre Habouzit <madcoder@debian.org> 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
>> intervention.
>>
>> 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
intent.

> 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 
> key.

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?

MfG
        Goswin