New Key Repo Locations

[Jeroen van Meeuwen]

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