New Key Discussion

[Warren Togami]

(Copying to list so there is a public record.)

Below are some notes toward forming a recommendation for FESCO for the
procedure of reissuing the new keys and how we will handle the packages
in the repository.  Please add your comments.

1) Generate new key for F8 and F9 stable, and a separate key for testing.

The goal of this new key would be to upgrade from "high certainty" to
"full known certainty" in the integrity of package signatures.

2) Announce new key and instructions for users because most users will
be required to install the new fedora-release manually.

Unfortunately, nobody could think of a fool-proof way to automate
getting the new key to users.  We considered issuing a new
fedora-release signed by the old key.  This idea was rejected because
after another update is issued with the new key, then the transaction
requires manual intervention to succeed.  There is simply no escaping
the need to manually install the new key.

(Any other ideas?)

On the plus side: Unlike PK at F9 GA, the latest PK in F9 updates can
now ask the user if they wish to import a key.

3) Begin using the new key immediately to sign new updates.

4) Begin resigning all existing F8, F9, update and testing packages in
repos, leave ISO's alone.   Replace content on mirrors over time.

According to Jesse this step would require ~3 weeks of time.  For this
reason it may be impractical to do this prior to

Crap.  I just realized that anybody behind a caching proxy server will
have severe issues when mirror content is resigned.  Packages will
inconsistently appear to be the old key long after they were signed
because their contents changed but their URL did not.  The only way we
will avoid a many broken users and mass complaints is to make an updated
version of yum smarter when faced with X-Cache headers.

5) In a few weeks after all F8+ packages are resigned with the new key,
revoke the old key.  The only way we can revoke the old key is to rpm -e
it.  Unfortunately, skvidal did some research into ways we could
possibly achieve this and our options are not good.  rpm -e is
impossible during rpm %post because it locks the transaction.  We really
do need a way to automate revocation of the old key.  It seems we have a
few weeks to figure out a way to do it.

(Idea: Perhaps we add a hack to rpm itself in a package update?  Ugly as
hell, but what other options do we have?)

During the meeting it was discussed that we might issue a new key and
keep the existing packages signed with the old key.  This idea was
rejected because there would be almost no point in generating a new key.

6) Fedora 10 will have its own key generated according to Jesse.

7) We should really consider a "master key" mechanism for future Fedora
releases that would allow us to automate revocation of an old key and
automate migration to a new key in a way that does not require manual
intervention of the user.  The master key would sign any new key
generated.  The master key would be kept somewhere away from any
networked computer.

Warren Togami
wtogami at redhat.com