Warren Togami wrote:

This is the latest draft of New Key repo locations. Jesse Keating points out that the deep levels are necessary because mirrors exclude releases by directory name like "9/". Please let me know if you see any errors in the below.

If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either.

Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from.

Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)?

Kind regards,

Jeroen van Meeuwen -kanarip

Sorry for the top post, I'm on my crackberry. We need to male sure to CLEARLY communicate this to mirror admins. I'm sure that more than 1 excludes releases/9/ since it is considered to be static content after release in order to reduce the number of files for rsync to consider.

On 8/28/08, Jesse Keating jkeating@redhat.com wrote:

On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:

...

If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either.

Yes, if 9 is excluded (or included) that means the admin either doesn't care about 9 and doesn't want to mirror it, or explicitly cares about it and only wants to mirror it. Either way I wish to honor those choices by not changing the top level directory where "9" or "8" will be. This also means we won't have to re-file our export approval.

...

Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from.

At this time, the isos will not be respun. We will however re-sign the SHA1SUM file with the new gpg key. We are certain that the content on the ISOs (and the numerous hard copies floating about) are safe. The only content to be left in the repos these isos will be able to access out of the box will be the transition fedora-update release, and the fixed packagekit for gpg importing. We'll also have mirrormanager direct all requests for the old dir directly to mirrors which we have ultimate control over.

...

Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)?

It was considered briefly, but not very much. Calling something 9.1 would also have a bit of an assumption that we've fixed some bugs or otherwise made it a better release, which we aren't doing. We're merely re-signing content and placing it in a slightly different directory, but it's still 9, not 9+something. (ditto 8)

-- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating

Jesse Keating wrote:

On Fri, 2008-08-29 at 01:51 +0200, Jeroen van Meeuwen wrote:

...

If 9/ is excluded, wouldn't that mean 9/$releasever/*/os.newkey is also excluded? If it's not, then I guess there's no point in the new directory being created either.

Yes, if 9 is excluded (or included) that means the admin either doesn't care about 9 and doesn't want to mirror it, or explicitly cares about it and only wants to mirror it. Either way I wish to honor those choices by not changing the top level directory where "9" or "8" will be. This also means we won't have to re-file our export approval.

So, if 9/ is excluded from, say, the hourly sync a mirror does (since it only needs to be mirrored once), the os.newkey/ won't end up on the mirror, which is my primary concern. (I guess this has been answered, partly, in another reply in this thread already).

...

Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from.

At this time, the isos will not be respun. We will however re-sign the SHA1SUM file with the new gpg key. We are certain that the content on the ISOs (and the numerous hard copies floating about) are safe. The only content to be left in the repos these isos will be able to access out of the box will be the transition fedora-update release, and the fixed packagekit for gpg importing. We'll also have mirrormanager direct all requests for the old dir directly to mirrors which we have ultimate control over.

I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files.

For the other part, where mirrormanager directs requests to mirrors we have ultimate control over... is this going to interfere with the local mirrors someone like myself may have set up at home and at multiple customer sites? E.g., will clients in these netblocks be redirected to mirrors the Fedora Project has ultimate control over, or am I misunderstanding what you are saying?

...

Has creating/composing an entirely new 9.1/ release tree been considered? I guess recreating the entire release tree is a PITA (jigdo, iso, torrent, foo) even though updates would not be included other then maybe the updated fedora-release package (with the new rpm-gpg-keys and new repo configuration files)?

It was considered briefly, but not very much. Calling something 9.1 would also have a bit of an assumption that we've fixed some bugs or otherwise made it a better release, which we aren't doing. We're merely re-signing content and placing it in a slightly different directory, but it's still 9, not 9+something. (ditto 8)

This sounds to me like a not-really-technical argument. You're right in that the naming in releases/X.Y does imply a new and improved install tree. I think there's some other serious consequences to choosing to do it in the original X/ release tree though. I'm thinking, who gives a c* that there's not actually 'new and improved' content in the trees even though the naming suggests that there is, while it does carry an entirely new tree with ISOs and jigdo's and stuff that have the new signed content and make a full match between what you download and what you start using, like with a normal release.

Kind regards,

Jeroen van Meeuwen -kanarip

Jeroen van Meeuwen wrote:

...

...

Will the ISOs be respun to reflect the changes as well so that what is in os/ or in os.newkey/ meets what each of the ISO expects? I guess this is primarily relevant to respins, netinstalls and so forth, as the old RPM-GPG-KEYs will be in the root of those ISOs and I can only presume they are used, and people will want to use os.newkey/ as the tree to install from.

At this time, the isos will not be respun. We will however re-sign the SHA1SUM file with the new gpg key. We are certain that the content on the ISOs (and the numerous hard copies floating about) are safe. The only content to be left in the repos these isos will be able to access out of the box will be the transition fedora-update release, and the fixed packagekit for gpg importing. We'll also have mirrormanager direct all requests for the old dir directly to mirrors which we have ultimate control over.

I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files.

You misunderstand the New Key plan. Mirrormanager for the existing repos fedora, updates and updates-testing will not redirect to the new location. Please read the plan again carefully.

Warren Togami wtogami@redhat.com

I think this is what you're looking for

http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html

2008/8/29 Axel Thimm Axel.Thimm@atrpms.net

On Fri, Aug 29, 2008 at 12:15:23AM -0400, Warren Togami wrote:

...

Jeroen van Meeuwen wrote:

...

I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files.

You misunderstand the New Key plan. Mirrormanager for the existing repos fedora, updates and updates-testing will not redirect to the new location. Please read the plan again carefully.

Hi,

where can this plan be read, I didn't see it in this list or any URL pointing to it.

W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow? -- Axel.Thimm at ATrpms.net

---

Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

Jesse Keating wrote:

On Fri, 2008-08-29 at 02:32 +0200, Jeroen van Meeuwen wrote:

...

I'm not sure how that solves the net install use case, especially if mirrormanager is going to redirect to os.newkey/, as signatures used on os.newkey/ packages will not meet what the installer expects the signature to be on these files.

See bug 998. Installer doesn't expect keys.

Right, that one slipped my mind. I guess that addresses the concern of net installations as well.

...

For the other part, where mirrormanager directs requests to mirrors we have ultimate control over... is this going to interfere with the local mirrors someone like myself may have set up at home and at multiple customer sites? E.g., will clients in these netblocks be redirected to mirrors the Fedora Project has ultimate control over, or am I misunderstanding what you are saying?

It's only for the queries for the old location. This drives all queries for the old locations to our server so that we can get them the transition fedora-release, pk and nothing else.

This invalidates the .jigdo files then, right? These query the mirrorlist for the old location and need an old RPM file (or the checksums won't match).

Once they get the new

fedora-release, they'll be hitting the new url, which mirror manager will do the normal thing, drive them to site local, or drive them to geo locations. As to what to do about site local mirrors for the old location, I don't think that has been fully discussed, that's probably a good item for nit-picking.

I guess if queries for the old location is redirected to a mirror fp.o has ultimate control over, just to update fedora-release and pk, it would not really pose a big problem as the clients will be redirected back to their local mirrors once they get these two updates. I'm sure there's some situations that block access to mirrors other then their own local mirror, but the admins at these locations should be smart enough to rewrite the requested URL in a (transparent?) proxy (which I presume they'll have anyway).

It's a lot of work for little gain. What you're downloading, the isos, and what you start using, the content from the isos, will be matching, the same. It's the updates or extra packages you install after that which will have a new key on them. Rpm doesn't currently possess a way to verify the GPG keys on installed packages, so I'm told, so those installed from isos having the old key doesn't much matter. It's the new packages one would fetch over the internet that matter.

Given that one bug that slipped my mind, you're right... Not even including the updates/ and/or updates.newkey/ repository during the installation would form a problem. For the composing part, I don't see how including os.newkey/ and updates.newkey/ would form a problem (even though it might).

Kind regards,

Jeroen van Meeuwen -kanarip

Axel Thimm wrote:

On Fri, Aug 29, 2008 at 12:54:40PM +0200, Jeroen van Meeuwen wrote:

...

Axel Thimm wrote:

...

W/o knowing all details, why not move os to os.oldkey and use os as the new key's content? If the key is considered compromised what mirror admin would like to keep the old signed packages around anyhow?

I think then the problem becomes that every existing installation points to os/ where it would need os.oldkey/ to get the packages it can check gpg keys on.

But isn't this desired behaviour? We don't actually want os.oldkey/ to be used anymore (mid-term) as we need to revoce the key in case it has been stolen. Maybe we don't need os.*key at all.

E.g. if a key has been stolen, burn all signed stuff and recreate them with a new key.

The problem then becomes that a fedora-release package update needs to come from the old location which is the only location a currently running client knows about, signed with the old key (which again is all the running client knows about at this point).

In addition, I think they are burning everything-but-the-relevant pieces (such as a fedora-release file with an updated repo config, and the packagekit update that is able to gpg key import).

Kind regards,

Jeroen van Meeuwen

Axel Thimm wrote:

If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open.

(...snip...)

I agree with you for the most part, but I'll leave the risk assessment and corresponding consequential response paradigm to the ones that know best what happened and are actually in a position to decide whether or not to revoke keys and nuke content or to make it an easy transition now just to be safe rather then sorry.

Kind regards,

Jeroen van Meeuwen -kanarip

On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote:

2008/8/29 Axel Thimm Axel.Thimm@atrpms.net:

...

If ATM the key is considered stolen, the users need to stop using the key immediately anyway. Issuing a new package signed with the old key is just keeping the racing window open.

I don't think that the key is considered stolen atm. What has happened (to my limited knowledge) is that the machine storing the (encrypted) key was compromised, however, during the window of the compromise, the passphrase to the key was not entered. Therefore, what "they" have is an encrypted key that "they" don't know the passphrase to.

...

IOW the users do need to acknowledge the change of keys (like you do when an ssh host key has been changed). Otherwise any user with an F9 DVD is susceptible for being spoofed anyway, we won't be able to cure that: The people that stole the key just need to get control over a

Let's assume that the key *was* actually compromised, passhphrase and all. With the current plan, without additional intermediate compromises (say the user's DNS server), I still don't see the risk. We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over.

I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is. One of them is mine, and for what I know I could be the one having stolen the key injecting bad packages right now. Or maybe the key & passphrase show up on some hacker forums and anyone and his cat will be able to spoof us up.

Also most security breaches actually happen with insider knowledge, so I could have registered a mirror just for trojaning the users that would be redirected to me. We'll see what the investigation will turn up, maybe we will see former Fedorians exercising criminal skills alongside packaging.

Therefore, "they" can setup a mirror and sign stuff with the old key, but it won't be used by the default config.

Why not? See above. Maybe new mirrors since the incident have not been allowed to registered, but what if the intruder registered them beforehand?

Which brings up an interesting question in my mind - how are we ensuring that the old key is actually removed from user machines and no longer trusted? I remember something about the new fedora-release obsoleting the old key, but that was seen as not something we could do. Why not?

I also don't see a reason. Removing a key in %pre or %post is not an issue with rpm >= 4.3 (maybe even earlier).

...

The only way to not have this happen is to loudly announce that the old key is being revoked and content signed with it needs to be cast away and replaced.

That's pretty much what's happening. The issue that we have with a clean transistion is that the PackageKit that was included in Fedora 9 GA did not have the ability to import new keys, and we want this transition to be as painless as possible for our users.

Possibly better to have a non-painless and non-automatic transition, so F9 DVD owners don't get into any bad mirrors.

...

All this assumes that there is real suspicion that the old key has been stolen, but the new key procedure does indicate that case. Otherwise, if it is just being done for good measure, then it's a bad step.

Why is it bad to exercise an abundance of caution in this situation?

Because there is not really such a thing as a grey zone in security assertions, it is either a security issue (of a certain gravity) or not.

Either the key is considered compromized and one needs to do the full program, or it is reasonably considered safe (by a brute-force safe passphrase and really assuming the passphrase has not been lost to the intruder as well), in which case no steps are needed, but phasing it out before the computing power gets accessible to break it (e.g. new keys for F10 upwards).

The current program looks like a mix of assuming "safe" (so the old key can be used for signing new packages, even if it just a few) and assuming "compromised" needing a resiging of all content.

But actually w/o knowing the details and the outcome of the current investigation one can't really say much. It just looks like contradicting security measures (assuming "safe" vs "compromized").

[1] # lynx --dump 'http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=x86_64' # repo = fedora-9 arch = x86_64 Using preferred netblock Using Internet2 countr y = DE country = RO country = GB country = PL country = EE country = IT country = ES country = MD country = IL country = FR country = FI country = NL country = NO country = CH country = CZ country = SE country = DK country = LV country = IS country = AT country = IE http://mirror.atrpms.net/fedora/linux/releases/9/Everything/x86_64/os http://mirror.fraunhofer.de/download.fedora.redhat.com/fedora/linux/releases... Everything/x86_64/os http://sunsite.informatik.rwth-aachen.de/ftp/pub/Linux/fedora/linux/releases... Everything/x86_64/os http://ftp.stw-bonn.de/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.uni-bayreuth.de/linux/fedora/linux/releases/9/Everything/x86_64/o... http://ftp.uni-koeln.de/mirrors/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.sunet.se/pub/Linux/distributions/fedora/linux/releases/9/Everything/x 86_64/os http://ftp.rhnet.is/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.esat.net/mirrors/download.fedora.redhat.com/pub/fedora/linux/rele... s/9/Everything/x86_64/os http://ftp.cica.es/fedora/linux/releases/9/Everything/x86_64/os http://ftp.iasi.roedu.net/mirrors/fedora.redhat.com/linux/releases/9/Everyth... /x86_64/os http://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/releases/... verything/x86_64/os http://ftp.sh.cvut.cz/MIRRORS/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.rediris.es/mirror/fedora-redhat/releases/9/Everything/x86_64/... ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everything/ x86_64/os http://ftp.SURFnet.nl/pub/os/Linux/distr/fedora/linux/releases/9/Everything/... _64/os http://ftp.lip6.fr/ftp/pub/linux/distributions/fedora/releases/9/Everything/... _64/os http://ftp.crc.dk/fedora/linux/releases/9/Everything/x86_64/os http://fr2.rpmfind.net/linux/fedora/releases/9/Everything/x86_64/os http://ftp.ps.pl/pub/Linux/fedora-linux/releases/9/Everything/x86_64/os http://mirror.switch.ch/ftp/mirror/fedora/linux/releases/9/Everything/x86_64... http://ultra.linux.cz/MIRRORS/fedora.redhat.com/linux/releases/9/Everything/... _64/os http://ftp.heanet.ie/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.klid.dk/ftp/fedora/linux/releases/9/Everything/x86_64/os http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/lin... releases/9/Everything/x86_64/os http://gd.tuwien.ac.at/opsys/linux/fedora/linux/releases/9/Everything/x86_64... http://ftp.wcss.pl/pub/linux/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.uvsq.fr/pub/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.cru.fr/pub/linux/fedora/releases/9/Everything/x86_64/os http://mirrors.linux.edu.lv/ftp.redhat.com/pub/fedora/linux/releases/9/Every... ng/x86_64/os ftp://ftp.uib.no/pub/fedora/linux/releases/9/Everything/x86_64/os http://ftp.man.poznan.pl/pub/linux/fedora/releases/9/Everything/x86_64/os http://ftp.linux.org.uk/pub/distributions/fedora/linux/releases/9/Everything... 6_64/os http://fedora.inode.at/fedora/linux/releases/9/Everything/x86_64/os ftp://ftp.pbone.net/pub/fedora/linux/releases/9/Everything/x86_64/os http://fedora.fastbull.org/linux/releases/9/Everything/x86_64/os ftp://ftp.proxad.net/mirrors/fedora.redhat.com/fedora/linux/releases/9/Everythi ng/x86_64/os http://ftp.gui.uva.es/sites/fedora.redhat.com/linux/releases/9/Everything/x8... 4/os http://ftp.crihan.fr/mirrors/fedora.redhat.com/fedora/linux/releases/9/Every... ng/x86_64/os http://redhat.linux.ee/pub/fedora/linux/releases/9/Everything/x86_64/os http://sunsite.icm.edu.pl/pub/Linux/fedora/linux/releases/9/Everything/x86_6... s

Matt Domsch wrote:

On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote:

...

On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote:

...

We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over.

I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is.

that's the plan, it's not implemented yet. In fact, I'll probably just do it with plain HTTP redirects in an httpd.conf file rather than special-case it in MM.

http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html Matt, you are misunderstanding the plan. No redirections are necessary at any level of this plan.

Warren

On Sat, 2008-08-30 at 23:53 -0400, Warren Togami wrote:

Axel Thimm wrote:

...

Either the key is considered compromized and one needs to do the full program, or it is reasonably considered safe (by a brute-force safe passphrase and really assuming the passphrase has not been lost to the intruder as well), in which case no steps are needed, but phasing it out before the computing power gets accessible to break it (e.g. new keys for F10 upwards).

The current program looks like a mix of assuming "safe" (so the old key can be used for signing new packages, even if it just a few) and assuming "compromised" needing a resiging of all content.

It turns out that we're ahead of schedule in re-signing. Due to bodhi limitations we needed to resign all updates before pushing any new updates, and that is done now. I have to check with Jesse but I suspect resigning of Everything should be done early during this upcoming week. (It might even be close to done now, I dunno.)

http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html The re-signing of Everything however is not blocking implementation of the first stages of the plan - which includes updates going out.

Anyhow, updates should begin flowing soon, and shortly thereafter the old key is removed. Oh, did you actually test rpm -e during %post? According to skvidal it doesn't work because it locks the transaction. Jeremy thinks the only assured way we can remove the old key is with a hardcoded hack in rpm that will be removed in F10 rpm.

I tested rpm -e during %post on two f9 systems, It locked the rpmdb hard.

-sv

How about as an alternative to creating new SRPMS.newkey etc folders to overcome the proxy issues, to keep it canonical and instead release 9.1 and 8.1?

The benefits, other than staying in line with the established layout practices are that one could merge in the updates (like the unity project does) and even offer an advantage to the user when installing from 9.1. Furthermore one could always check whether a system is "vulnerable" by checking its version.

Or does this need export regulations due to changing the version number? Hopefully not.

On Sun, Aug 31, 2008 at 01:18:25AM -0700, Toshio Kuratomi wrote:

Warren Togami wrote:

...

Matt Domsch wrote:

...

On Sat, Aug 30, 2008 at 07:46:31PM +0300, Axel Thimm wrote:

...

On Fri, Aug 29, 2008 at 02:56:38PM -0400, Jon Stanley wrote:

...

We're using MM to redirect ALL requests for the old repo location to mirrors that we have ultimate control over.

I don't think that's true, see [1] for 64 mirrors that are suggested for my location that are certainly not under Red Hat/Fedora control, actually it looks like none is.

that's the plan, it's not implemented yet. In fact, I'll probably just do it with plain HTTP redirects in an httpd.conf file rather than special-case it in MM.

http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html Matt, you are misunderstanding the plan. No redirections are necessary at any level of this plan.

Warren, I think we need to add redirection as step 6.1.

If we don't lock out mirrors that we don't control at that stage, there's nothing to prevent the following scenario::

Person with the key has brute forced passphrase and compromises mirror. uploads packages signed with old key to the F-9 repo on the old mirror. Among other things these packages subvert yum so that it will only update from compromised mirrors and removes the new key from the NEWREPO. User downloads F-9 ISO. Installs F-9 with old key as valid. User hits the compromised mirror on first yum update and installs compromised packages.

I more and more like the idea of killing F8 and F9 and going F8.1 and F9.1. The person with the F9 DVD might even manually download a bad signed package and think it is Fedora signed. He might even turn on malicious or compromized 3rd party repos that carry malicious packages signed with the old key and not notice how willing his DVD install will swallow these packages in.

Once again, either the intruder is considered unable to sign packages due to a very good passphrase (and then we don't even need to start this stepdance), or if signed malware is realistic then the old key and all assorted bits need to be considered dead including old F9 DVDs. Much more than RHEL Fedora is an open system with many software flow channels from volunteer mirrors to 3rd party repos, driver ISVs, sf.net rpms, etc. as well as manual installs. So even if the Fedora mirrors issue is dealt with there are still lots of open spots.

I propose to

a) resping F8/F9 with updates (all signed with the new key) to create 8.1, 9.1. Fedora unity recenty did some respins, so maybe it is just cut and paste. b) empty F8/F9 updates and just place a package in there that will automatically upgrade any F8/F9 system to F8.1/F9.1. Redirect all mirrormanager controlled URLs to a controlled entity that only serves this package for F8/F9. Being a single package this will be a much lighter load than turning off all mirrors. The mirrors will still be used for 8.1/9.1. c) make sure users get alerted about this, maybe by some applet.

On Sun, 2008-08-31 at 10:35 +0300, Axel Thimm wrote:

The benefits, other than staying in line with the established layout practices are that one could merge in the updates (like the unity project does) and even offer an advantage to the user when installing from 9.1. Furthermore one could always check whether a system is "vulnerable" by checking its version.

Or does this need export regulations due to changing the version number? Hopefully not.

It would need new export controls, which is the least of the problems.

We are going to have a hard enough time doing a full release for Fedora 10, trying to squeeze in a 9.1 and an 8.1 release is just going to make 10 that much worse. Add to that it won't help at all the already burned or mastered copies of the original isos in existence.