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@centos-5 ~]$ date ; srcfind MirrorManager Tue Aug 18 12:36:25 EDT 2009 /home/herrold/.tmp/srcfind.cache.txt MirrorManager nil [herrold@centos-5 ~]$
URL please
https://fedorahosted.org/mirrormanager/
https://fedoraproject.org/wiki/Infrastructure/MirrorManager
https://fedoraproject.org/wiki/Infrastructure/Mirroring
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:
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=...
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.