rel-eng August 2008

rel-eng@lists.fedoraproject.org

18 participants
29 discussions

iozone is a dead.package in rawhide
by Tom Callaway 27 Aug '08

27 Aug '08

Due to licensing issues (iozone's license doesn't grant permission to modify), I've dead.package'd iozone in devel. Please block it from rawhide and all future dists. Thanks, ~spot

2 1

New Key Discussion v2 for FESCO Meeting
by Warren Togami 27 Aug '08

27 Aug '08

(Copying to FESCO list for discussion. I propose that FESCO looks over the following plan and voice any concerns. But for the sake of time, I recommend that FESCO vote to allow rel-eng the autonomy to execute so we do not have further delays in getting updates out.) This version is updated with an auto-key migration proposal by wwoods and mbonnet. Jeremy and I think it is a decent plan. There is also an auto-revoke plan. 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) Resigning all existing F8, F9, update and testing packages in repos, leave ISO's alone. When resigned content is ready, remove the RPMS from old repo, and put the resigned RPMS into new repo. (WOO HOO!! This actually solved the proxy cache issue, since the URL's of the changed content actually changes.) 7) After all old repo is emptied, 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, remove this hack for F10 rpm, and add it to Anaconda instead. With this new rpm, is a 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. Let us NOT decide on this now. Agreeing to steps 1 through 5 are most critical in the short-term. Warren Togami wtogami(a)redhat.com

1 0

Re: New Key Discussion for FESCO Meeting
by Toshio Kuratomi 27 Aug '08

27 Aug '08

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

2 1

New Key Discussion
by Warren Togami 26 Aug '08

26 Aug '08

(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(a)redhat.com

4 5

Test 1 2 3
by Jeffrey Ollie 26 Aug '08

26 Aug '08

Test 1 2 3 -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

1 0

[Fedora Release Engineering] #763: Give Legal heads up on Alpha release
by Fedora Release Engineering 04 Aug '08

04 Aug '08

#763: Give Legal heads up on Alpha release -----------------------------+---------------------------------------------- Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: Fedora 10 Alpha | Component: other Keywords: | -----------------------------+---------------------------------------------- Email legal to make sure they are aware of the Alpha release and can file any paperwork necessary. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/763> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 0

[Fedora Release Engineering] #67: Compose Fedora 10 Alpha Live images
by Fedora Release Engineering 04 Aug '08

04 Aug '08

#67: Compose Fedora 10 Alpha Live images -----------------------------+---------------------------------------------- Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: Fedora 10 Alpha | Component: other Keywords: | -----------------------------+---------------------------------------------- Compose live images from f10-alpha content for all the primary Live targets. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/67> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

[Fedora Release Engineering] #66: Compose Fedora 10 Alpha "Fedora" trees
by Fedora Release Engineering 04 Aug '08

04 Aug '08

#66: Compose Fedora 10 Alpha "Fedora" trees -----------------------------+---------------------------------------------- Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: Fedora 10 Alpha | Component: other Keywords: | -----------------------------+---------------------------------------------- Compose the "Fedora" trees for all primary arches using the content from f10-alpha. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/66> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

[Fedora Release Engineering] #761: Block isicom from rawhide (and all future Fedora releases)
by Fedora Release Engineering 01 Aug '08

01 Aug '08

#761: Block isicom from rawhide (and all future Fedora releases) ----------------------------+----------------------------------------------- Reporter: spot | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: Fedora 10 Beta | Component: koji Keywords: | ----------------------------+----------------------------------------------- the "isicom" package is now a dead.package, it depended on a kernel driver we hadn't been enabling, and included binary firmware without any licensing. Please block it from rawhide and all future Fedora releases. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/761> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng August 2008