Warren Togami wrote:
(Copying to FESCO list for discussion. I propose that FESCO looks
over
the recommended steps below. If anything looks disagreeable please let
rel-eng know. Otherwise I propose that FESCO vote to allow rel-eng the
autonomy to implement a plan similar to below so we don't have to wait
another week for another FESCO vote to decide how we will handle the
rekeying.)
I'm sending to rel-eng and CC'ing FESCo list.
6) In a few weeks after all F8+ packages are resigned with the new key,
revoke the old key. The only way we can revoke the old key is to rpm -e
it. Unfortunately, skvidal did some research into ways we could
possibly achieve this and our options are not good. rpm -e is
impossible during rpm %post because it locks the transaction. We really
do need a way to automate revocation of the old key. It seems we have a
few weeks to figure out a way to do it.
Did anyone look into geppetto's idea to have the new fedora-release
Obsolete the old key?
[snip]
8) We should really consider a "master key" mechanism for
future Fedora
releases that would allow us to automate revocation of an old key and
automate migration to a new key in a way that does not require manual
intervention of the user. The master key would sign any new key
generated. The master key would be kept somewhere away from any
networked computer.
Does this work better than having two keys in fedora-release? one of
which is the key that is used and the other which is a backup? (ie, the
public key is disseminated with fedora-release but the private key is
kept off of a networked computer. If we need to resign all packages, we
sign the packages with this backup key. And issue a new fedora-release
signed with this key and containing this key and a freshly generated
backup key)
-Toshio