New Key Discussion v3

Warren Togami wtogami at redhat.com
Wed Aug 27 21:37:18 UTC 2008


1) Rel-eng gets security team's approval to the below plan.

2) 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.

3) AUTOMATIC KEY MIGRATION
New fedora-release contains NEW KEY, and NEW .repo file.  New repo is
pointing at a new location on the mirror.  This fedora-release is put
into the OLD repo, signed by the OLD key.

User upgrades into the new fedora-release and latest PackageKit, then
subsequent update will point at the new repo.  Old .repo definition is
untouched at this point.

New repo contains subsequent Fedora updates signed by the new key.

4) Announce about the new key and let everyone be aware of the details
of this migration and user impact.

5) Push updates signed by the new key into the new repo.

6) Resign all existing F8, F9, update and testing packages in repos,
leave ISO's alone.   When resigned content is ready, minimize contents
of OLD repo, and put the resigned RPMS into new repo.  The minimized OLD
repo contains only minimal deps to upgrade into the new fedora-release,
and new PackageKit required to handle key import.

(WOO HOO!!  This actually solved the proxy cache issue, since the URL's
of the changed content actually change.)

7) After OLD repo is cleaned, issue a new rpm update in NEW repo.
This rpm contains an ugly hardcoded hack to eliminate the old key.  This
sucks a lot, but Jeremy and I think this is our cleanest option.  Jeremy
thinks we can remove this hack for F10 rpm, and add it to Anaconda instead.

Alongside this new rpm in NEW repo, is another new fedora-release that
deletes the OLD .repo file.

8) Fedora 10 will have its own new key.

9) For Fedora 10 let us consider a better way to handle automatic key
migration.  The "master key" or Toshio's simpler "secondary key" plans
were proposed.  Other methods are possible.

10) As a separate matter, decide if we want to resign the RPMS in the ISO's.

Warren Togami
wtogami at redhat.com



More information about the rel-eng mailing list