From Fedora Project Wiki

(Wiki page for signing plan)
 
(→‎Fedora Signing Key Plan: Update with more progress)
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Fedora Signing Key Plan =
As a result of [https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html the recent intrusion], and out of an abundance of caution, the Fedora Project has decided to issue new package signing keys.  As [https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00012.html announced previously], this process may require users to take affirmative steps to continue receiving updates from official Fedora mirrors.


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]].
= For Fedora Users =


== Plan Steps ==
{{Admon/important | Read these instructions! | Fedora users should visit [[Enabling_new_signing_key | these instructions]] to learn how to enable the new key.}}


1. Release-Engineering obtains the security team's approval to the below plan. (completed)
We will soon be posting [[Enabling_new_signing_key | detailed instructions]] for users to enable the new package signing key. By enabling the new package signing key, your system can continue to receive security, bug fix, and enhancement updates from the official Fedora mirrors.  Systems that do not enable the new key may not be able to receive these udpates.


2. Generate a new key for F8 and F9 stable and a separate key for testing.
= Fedora Signing Key Plan =
 
3. Automatic key migration.
 
4. Announce the new key and details of the migration and end-user impact.
 
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.
 
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.
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].


10. Decide if the RPMS in the existing .iso's will be re-signed.
# {{check}} Release engineering obtains the security team's approval to the plan shown below.
# {{check}} Generate a new key for F8 and F9 stable, and a separate key for testing.
# {{check}} Automatic key migration.
# {{check}} Announce the new key and details of the migration and end-user impact.
# {{check}} Push updates signed by the new key into the new repository.
# {{check}} Re-sign all existing F8 and F9 update and testing packages in the repository.
# {{check}} Minimize contents of the old updates(-testing) repository to contain 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)
# {{check}} Re-sign all existing F8, and F9 release packages in the repository, leaving the .iso's alone.
# When the re-signed content is ready, remove contents of the old repository and put the resigned RPMS into a new repository. (in progress)
# After the old repository is cleaned, issue a new rpm update in the new repository that will purge old key from user's rpmdb.
# {{check}} Create new key for Fedora 10.
# During development and release of Fedora 10, consider and create better ways to handle automatic key migration. (in progress)
# Decide if the RPMS in the existing .iso's will be re-signed.

Latest revision as of 21:08, 20 October 2008

As a result of the recent intrusion, and out of an abundance of caution, the Fedora Project has decided to issue new package signing keys. As announced previously, this process may require users to take affirmative steps to continue receiving updates from official Fedora mirrors.

For Fedora Users

Important.png
Read these instructions!
Fedora users should visit these instructions to learn how to enable the new key.

We will soon be posting detailed instructions for users to enable the new package signing key. By enabling the new package signing key, your system can continue to receive security, bug fix, and enhancement updates from the official Fedora mirrors. Systems that do not enable the new key may not be able to receive these udpates.

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.

  1. Checkmark.png Release engineering obtains the security team's approval to the plan shown below.
  2. Checkmark.png Generate a new key for F8 and F9 stable, and a separate key for testing.
  3. Checkmark.png Automatic key migration.
  4. Checkmark.png Announce the new key and details of the migration and end-user impact.
  5. Checkmark.png Push updates signed by the new key into the new repository.
  6. Checkmark.png Re-sign all existing F8 and F9 update and testing packages in the repository.
  7. Checkmark.png Minimize contents of the old updates(-testing) repository to contain 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)
  8. Checkmark.png Re-sign all existing F8, and F9 release packages in the repository, leaving the .iso's alone.
  9. When the re-signed content is ready, remove contents of the old repository and put the resigned RPMS into a new repository. (in progress)
  10. After the old repository is cleaned, issue a new rpm update in the new repository that will purge old key from user's rpmdb.
  11. Checkmark.png Create new key for Fedora 10.
  12. During development and release of Fedora 10, consider and create better ways to handle automatic key migration. (in progress)
  13. Decide if the RPMS in the existing .iso's will be re-signed.