Fedora 7 definitely behaves differently than Fedora 8 and 9. The
behavior I describe began with F8. For F7 and earlier, the yum policy
would chose any random mirror from the returned list, so having many
mirrors on the list, some of which are unreachable from inside an
organization, would be bad. The yum default policy was changed to treat
the mirrorlist as a priority list, so MM returns a longer list.
Linux Technology Strategist, Dell Office of the CTO
From: Justin Samuel [mailto:email@example.com] On Behalf
Of Justin Samuel
Sent: Friday, July 25, 2008 1:36 PM
To: Domsch, Matt
Cc: Josh Bressers; Mike McGrath; fedora-infrastructure-list(a)redhat.com;
Justin Cappos; security(a)fedoraproject.org
Subject: Re: YUM security issues...
-----BEGIN PGP SIGNED MESSAGE-----
Matt Domsch wrote:
On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote:
> On 25 July 2008, Matt Domsch wrote:
>> Yes, this is a known challenge with subnet delegation in
>> MirrorManager. We're trusting package signing (and soon, repodata
>> signing) to prevent rogue mirrors from issuing unsigned data. In
>> addition, I'm working on adding in a way to prevent stale mirrors
>> (with signed content) from being used.
> How does one get this subnet delegation though? Can I request any
> want, or do we do some sort of verification?
At present there is no verification (I'm not at all sure how one
_could_ verify except by ARIN & co delegation). However there are
limits as to how large a block can be requested. Nothing larger than
a IPv4 /16 can be automatically requested. Fedora Infrastructure
admins can add larger blocks, and request ARIN & co data when doing
> What happens if the client decided its mirror is bad, I presume it
> off and find a better one, even with delegation?
Yes, the mirrorlist returned includes quite a few mirrors, in priority
Our testing showed that when our client was in a MirrorManager-defined
CIDR block for a mirror, the returned mirrorlist included only the
single mirror. -- It's dangerous either way, of course, but I'm just
wondering if our testing was faulty, if this has changed since we
tested, or if it might be behaving differently than you expect.
Possibly you tested with a block that was already defined by other
mirrors and so multiple entries were returned in the mirrorist? That's
just a guess, we didn't test with a block that was defined by more than
one mirror (as far as we knew, at least).
gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----