New Key Discussion v3
jwboyer at gmail.com
Wed Aug 27 22:02:10 UTC 2008
On Wed, Aug 27, 2008 at 05:37:18PM -0400, Warren Togami wrote:
> 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.
We need two more steps.
Hi, my name is Josh and I am a security plan junkie.
More information about the rel-eng