New Key Repo Locations

[Jesse Keating]

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.

> 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.  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.

> 
> >> 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.

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.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20080828/c97aba08/attachment.bin