Not sure how many of you guys have used fedora's mirror manager, but centos should do something like this. Its really a nice little app, that helps in mirroring.
On 08/18/2009 04:07 PM, Nick Olsen wrote:
Not sure how many of you guys have used fedora's mirror manager, but centos should do something like this. Its really a nice little app, that helps in mirroring.
howso ?
Its great when your looking for a mirror to pull from. It lists every mirror that your allowed to pull from, What they have, if its up to date. And where THEY pull it from. Not to mention they have some CGI script or something that ties into yum so you can redirect your local subnets to your local server insted of having to mod the repo file on every box.
On 8/18/2009 11:36 AM, Karanbir Singh wrote:
On 08/18/2009 04:07 PM, Nick Olsen wrote:
Not sure how many of you guys have used fedora's mirror manager, but centos should do something like this. Its really a nice little app, that helps in mirroring.
howso ?
On 08/18/2009 04:39 PM, Nick Olsen wrote:
Its great when your looking for a mirror to pull from. It lists every mirror that your allowed to pull from, What they have, if its up to date. And where THEY pull it from. Not to mention they have some CGI script or something that ties into yum so you can redirect your local subnets to your local server insted of having to mod the repo file on every box.
On 8/18/2009 11:36 AM, Karanbir Singh wrote:
On 08/18/2009 04:07 PM, Nick Olsen wrote:
Not sure how many of you guys have used fedora's mirror manager, but centos should do something like this. Its really a nice little app, that helps in mirroring.
howso ?
yes, that yum cgi thing you speak of - is also a massive security hazard. Its the no.1 reason why noone else wants to go down that route. As for the mirror network, if you are a public mirror you should be pulling from the msync targets anyway ( and we try and keep those controlled to ensure there is enough b/w to go around ).
We do need better monitoring within that, and is something we should get done soon.
If you are not a public mirror, you should *not* be pulling from anything .centos.org and just going to your trusted local upstream. There is potent to better define this and to merge in the various sources of info that exist on .centos.org!
What is this security hazard you speak of? I don't really see a problem with it at first glance.
And yes, i'm running a private mirror, and no, i do not pull from *.centos.org Centos, I pull from linux.mirrors.es.net
On 8/18/2009 11:44 AM, Karanbir Singh wrote:
On 08/18/2009 04:39 PM, Nick Olsen wrote:
Its great when your looking for a mirror to pull from. It lists every mirror that your allowed to pull from, What they have, if its up to date. And where THEY pull it from. Not to mention they have some CGI script or something that ties into yum so you can redirect your local subnets to your local server insted of having to mod the repo file on every box.
On 8/18/2009 11:36 AM, Karanbir Singh wrote:
On 08/18/2009 04:07 PM, Nick Olsen wrote:
Not sure how many of you guys have used fedora's mirror manager, but centos should do something like this. Its really a nice little app, that helps in mirroring.
howso ?
yes, that yum cgi thing you speak of - is also a massive security hazard. Its the no.1 reason why noone else wants to go down that route. As for the mirror network, if you are a public mirror you should be pulling from the msync targets anyway ( and we try and keep those controlled to ensure there is enough b/w to go around ).
We do need better monitoring within that, and is something we should get done soon.
If you are not a public mirror, you should *not* be pulling from anything .centos.org and just going to your trusted local upstream. There is potent to better define this and to merge in the various sources of info that exist on .centos.org!
On Tue, Aug 18, 2009 at 04:44:47PM +0100, Karanbir Singh wrote:
yes, that yum cgi thing you speak of - is also a massive security hazard. Its the no.1 reason why noone else wants to go down that route. As for the mirror network, if you are a public mirror you should be pulling from the msync targets anyway ( and we try and keep those controlled to ensure there is enough b/w to go around ).
The newest incarnation of MirrorManager is better, 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. Yum can then compare the secure hashes of the repomd.xml files from the mirrors with the hash from the genuine master as served over https to verify it hasn't been tampered with. If it doesn't match, yum just goes onto the next mirror in the list.
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
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
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?
of the repomd.xml files from the mirrors with the hash from the genuine master as served over https to verify it hasn't been tampered with. If it doesn't match, yum just goes onto the next mirror in the list.
-- Russ herrold
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.
On 08/21/2009 04:41 AM, Chuck Anderson wrote:
"CA cert checking integrated (both ways)."
This works, you can use the yum rpms presently in c5-testing to make sure. But it would only work for 5.4+ clients.
"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."
Much like bittorrent - remember there are many people who question the whole purpose of metalinks :) In this case, I think its just overdoing something essentially simple. And, there are better, client centric ways of doing this work, some which need more development done on.
btw, there is also the gpg signing of repomd's...
So we are getting there, but perhaps not quite perfect yet. Things are already much better than they were before.
the issue that most Fedora people seem unable to comprehend is that there is a whole world out there that does not reload every 6 months - therefore being able to track back and maintain some level of compatibility with the slightly older code base is something that confines much of what Fedora does today, to within Fedora lands. Some of these things might perculate down but then when they do, Fedora has moved onto other things.[1]
Reason I say this is that we cant just jump in and follow for Fedora is doing for the reason that we have a much longer and a broader product cycle and there is little ( many times none ) interest there to maintain and work with things they consider old and outdated. So while looking at MirrorManager is something we might be able to do today - whatever changes we make into the CentOS system need to be things that we know and can maintain in house. Many times that means rewriting based on and around our specific requirements.
- KB
[1]: It is refreshing and make me quite happy to see some of the infrastructure and tooling sub-projects / Fedora-upstreams take a more pragmatic approach on these things.
-
Chuck Anderson -
Karanbir Singh -
Nick Olsen -
R P Herrold