[CentOS-mirror] mirror manager

Fri Aug 21 03:41:26 UTC 2009
Chuck Anderson <cra at WPI.EDU>

On Tue, Aug 18, 2009 at 12:37:05PM -0400, R P Herrold wrote:
> On Tue, 18 Aug 2009, Chuck Anderson wrote:
> > The newest incarnation of MirrorManager is better,
> I see at RawHide ... nothing
> [herrold at centos-5 ~]$ date ; srcfind MirrorManager
> Tue Aug 18 12:36:25 EDT 2009
> /home/herrold/.tmp/srcfind.cache.txt
> MirrorManager     nil
> [herrold at centos-5 ~]$
> URL please





> > because it uses https:// URLs to the master server, which 
> > then serves a Metalink URL file containing the mirror list 
> > along with hashes of the files.
> and what revocation list checking exists and is implemented? 
> Are the hashes signed? If so, when and with what key security 
> model? traceable to what CA root set? -- so far all I see is 
> a potential for transit security of a file against a MitM

"MirrorManager may use HTTPS instead of HTTP upon request. However, as 
of Fedora 10, yum does not validate HTTPS certificates to ensure they 
were issued by a trusted certificate authority, so this is of limited 
value and not enabled by default in Fedora repo config files."

I don't know whether things are different now in Fedora 11 or 
Rawhide/12 w.r.t. certificate checking.  I do see that https:// URLs 
are being used by default in Fedora 11's yum config:


The yum roadmap lists this:

"CA cert checking integrated (both ways)."

The packages themselves are signed.  An attacker cannot inject new 
unsigned or differently signed updates.  The worst someone could do is 
a DoS--e.g. stop updates from getting to systems, but this is 
mitigated by the freshness checking done by yum using the metalink 
from the master server.

> > Yum can then compare the secure hashes
> 'can' is not 'does' -- version/release please? Is this in our 
> yum, or if not what adds it, so I can examine the model's 
> assumptions
> ehhh?  'secure hashes' how?  What is being compared here?

"Yum in Fedora 10 and higher can process the mirror list in metalink 
format, which provides additional security checking capability. Yum 
compares the SHA1 checksums of each repository's repomd.xml file 
against that of the master mirrors. This ensures that significantly 
out-of-date mirrors are not used."

So we are getting there, but perhaps not quite perfect yet.  Things 
are already much better than they were before.