New Key Discussion v3

Josh Boyer 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.

josh


More information about the rel-eng mailing list