(Wiki page for signing plan) |
mNo edit summary |
||
| Line 1: | Line 1: | ||
= Fedora Signing Key Plan = | = Fedora Signing Key Plan = | ||
This page outlines the new signing key plan that the Fedora Project is in the process of implementing. The history behind the plan can be found [[https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html | here]] and [[http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html | here]]. | This page outlines the new signing key plan that the Fedora Project is in the process of implementing. The history behind the plan can be found [[https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html | here]] and [[http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html | here]]. The release engineering team can be reached in #fedora-devel (irc.freenode.org) or emailed [mailto:rel-eng@fedoraproject.org rel-eng@fedoraproject.org]. | ||
== Plan Steps == | == Plan Steps == | ||
| Line 7: | Line 7: | ||
1. Release-Engineering obtains the security team's approval to the below plan. (completed) | 1. Release-Engineering obtains the security team's approval to the below plan. (completed) | ||
2. Generate a new key for F8 and F9 stable and a separate key for testing. | 2. Generate a new key for F8 and F9 stable and a separate key for testing. (completed) | ||
3. Automatic key migration. | 3. Automatic key migration. (completed) | ||
4. Announce the new key and details of the migration and end-user impact. | 4. Announce the new key and details of the migration and end-user impact. (in progress) | ||
5. Push updates signed by the new key into the new repository. | 5. Push updates signed by the new key into the new repository. | ||
| Line 18: | Line 18: | ||
leaving the .iso's alone. When the re-signed content is ready, minimize contents | leaving the .iso's alone. When the re-signed content is ready, minimize contents | ||
of the old repo and put the resigned RPMS into the new repository. The minimized old | of the old repo and put the resigned RPMS into the new repository. The minimized old | ||
repository contains only the minimal dependencies needed to upgrade to the new fedora-release. The new PackageKit required to handle key import will also be provided. | repository contains only the minimal dependencies needed to upgrade to the new fedora-release. The new PackageKit required to handle key import will also be provided. (in progress) | ||
7. After the old repository is cleaned, issue a new rpm update in the new repository. | 7. After the old repository is cleaned, issue a new rpm update in the new repository. | ||
Revision as of 16:13, 5 September 2008
Fedora Signing Key Plan
This page outlines the new signing key plan that the Fedora Project is in the process of implementing. The history behind the plan can be found [| here] and [| here]. The release engineering team can be reached in #fedora-devel (irc.freenode.org) or emailed rel-eng@fedoraproject.org.
Plan Steps
1. Release-Engineering obtains the security team's approval to the below plan. (completed)
2. Generate a new key for F8 and F9 stable and a separate key for testing. (completed)
3. Automatic key migration. (completed)
4. Announce the new key and details of the migration and end-user impact. (in progress)
5. Push updates signed by the new key into the new repository.
6. Re-sign all existing F8, F9, update and testing packages in the repository, leaving the .iso's alone. When the re-signed content is ready, minimize contents of the old repo and put the resigned RPMS into the new repository. The minimized old repository contains only the minimal dependencies needed to upgrade to the new fedora-release. The new PackageKit required to handle key import will also be provided. (in progress)
7. After the old repository is cleaned, issue a new rpm update in the new repository.
8. Fedora 10 will have its own new key.
9. The development and release of Fedora 10 will allow for consideration of better ways to handle automatic key migration.
10. Decide if the RPMS in the existing .iso's will be re-signed.