(Copying to list so there is a public record.)
Below are some notes toward forming a recommendation for FESCO for the procedure of reissuing the new keys and how we will handle the packages in the repository. Please add your comments.
1) 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.
2) Announce new key and instructions for users because most users will be required to install the new fedora-release manually.
Unfortunately, nobody could think of a fool-proof way to automate getting the new key to users. We considered issuing a new fedora-release signed by the old key. This idea was rejected because after another update is issued with the new key, then the transaction requires manual intervention to succeed. There is simply no escaping the need to manually install the new key.
(Any other ideas?)
On the plus side: Unlike PK at F9 GA, the latest PK in F9 updates can now ask the user if they wish to import a key.
3) Begin using the new key immediately to sign new updates.
4) Begin resigning all existing F8, F9, update and testing packages in repos, leave ISO's alone. Replace content on mirrors over time.
According to Jesse this step would require ~3 weeks of time. For this reason it may be impractical to do this prior to
Crap. I just realized that anybody behind a caching proxy server will have severe issues when mirror content is resigned. Packages will inconsistently appear to be the old key long after they were signed because their contents changed but their URL did not. The only way we will avoid a many broken users and mass complaints is to make an updated version of yum smarter when faced with X-Cache headers.
5) 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.
(Idea: Perhaps we add a hack to rpm itself in a package update? Ugly as hell, but what other options do we have?)
During the meeting it was discussed that we might issue a new key and keep the existing packages signed with the old key. This idea was rejected because there would be almost no point in generating a new key.
6) Fedora 10 will have its own key generated according to Jesse.
7) 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.
Warren Togami wtogami@redhat.com
On Tue, 2008-08-26 at 13:16 -0400, Warren Togami wrote:
- Begin resigning all existing F8, F9, update and testing packages in
repos, leave ISO's alone. Replace content on mirrors over time.
Josh suggested doing releases in whole, IE do all the F8 content, then all the F9 content. That could make it go a bit faster and not leave any users with mixed bags of signed content.
I'm only guessing on the 3 weeks thing, it could go faster, if I get clever with expect (but then I think the passphrase sits somewhere in the process list or memory or something, I'm not exactly comfortable with that).
Jesse Keating (jkeating@redhat.com) said:
Josh suggested doing releases in whole, IE do all the F8 content, then all the F9 content. That could make it go a bit faster and not leave any users with mixed bags of signed content.
I'm only guessing on the 3 weeks thing, it could go faster, if I get clever with expect (but then I think the passphrase sits somewhere in the process list or memory or something, I'm not exactly comfortable with that).
It should be doable piecemeal, correct - there's no reason we have to push them until all of a particular release is done?
Bill
Bill Nottingham wrote:
Jesse Keating (jkeating@redhat.com) said:
Josh suggested doing releases in whole, IE do all the F8 content, then all the F9 content. That could make it go a bit faster and not leave any users with mixed bags of signed content.
I'm only guessing on the 3 weeks thing, it could go faster, if I get clever with expect (but then I think the passphrase sits somewhere in the process list or memory or something, I'm not exactly comfortable with that).
It should be doable piecemeal, correct - there's no reason we have to push them until all of a particular release is done?
Piecemeal would be less sudden load on the mirrors to sync.
The caching proxy problem however will be equally bad no matter how we stage the resigned packages.
Warren
On Tue, 2008-08-26 at 13:16 -0400, Warren Togami wrote:
Below are some notes toward forming a recommendation for FESCO for the procedure of reissuing the new keys and how we will handle the packages in the repository. Please add your comments.
In the interest of getting this into FESCo's schedule, warren can you make a wiki page with this info and toss it to the fesco chair to get on the schedule? I don't know if my proposal template made the transition though :/
On Tue, Aug 26, 2008 at 12:16 PM, Warren Togami wtogami@redhat.com wrote:
- 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.
(Idea: Perhaps we add a hack to rpm itself in a package update? Ugly as hell, but what other options do we have?)
Drop a script in /etc/cron.hourly that rpm -e's the key and then deletes/disables itself.
rel-eng@lists.fedoraproject.org