New Key Repo Locations

[Jon Stanley]

Again, sorry about the top post. Anaconda doesn't expect any key at
install, see bug 998 for more details. F9's anaconda imports a key at
install, which in the respin case would probably need to be changed to
the new key. Other than that, I don't see a problem.



On 8/28/08, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> 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
> _______________________________________________
> rel-eng mailing list
> rel-eng at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/rel-eng
>

-- 
Sent from Gmail for mobile | mobile.google.com

Jon Stanley
Fedora Bug Wrangler
jstanley at fedoraproject.org