New Key Discussion v2 for FESCO Meeting
wtogami at redhat.com
Wed Aug 27 17:59:07 UTC 2008
(Copying to FESCO list for discussion. I propose that FESCO looks over
the following plan and voice any concerns. But for the sake of time, I
recommend that FESCO vote to allow rel-eng the autonomy to execute so we
do not have further delays in getting updates out.)
This version is updated with an auto-key migration proposal by wwoods
and mbonnet. Jeremy and I think it is a decent plan. There is also an
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) Resigning all existing F8, F9, update and testing packages in
repos, leave ISO's alone. When resigned content is ready, remove the
RPMS from old repo, and put the resigned RPMS into new repo.
(WOO HOO!! This actually solved the proxy cache issue, since the URL's
of the changed content actually changes.)
7) After all old repo is emptied, 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, remove this hack for F10 rpm, and add it to Anaconda instead.
With this new rpm, is a 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. Let us NOT decide on this now. Agreeing to steps 1 through
5 are most critical in the short-term.
wtogami at redhat.com
More information about the rel-eng