Yes, you clearly described one of the attacks we see with MirrorManager. A few comments: > 1) Have MirrorManager use https and return some repo verification data. Is the verification data a signed repomd.xml? Can you expand on this a little? By the way, before I forget it would be a good idea to avoid using a detached signature for repomd.xml. If you have the signature and data in separate files, you can have false positives for incorrect signatures (for example when the files are updated). > 2) Sign the repo data, and if it's older than X, don't use it (I don't like > this solution, but it's probably the easiest, just push out a new > signed repo file once a day, even if nothing changes.) You also want to make sure clients don't accept older versions of the metadata than what they've seen. In other words, if they'll accept metadata up to 1 week old, and they've downloaded metadata from yesterday, they shouldn't accept metadata that was signed 5 days ago. > 3) Always get repo data from fedoraproject.org (probably not practical due > to resource issues) I think this is similar to what openSUSE / SUSE Linux Enterprise do (they actually serve signed metadata from their Download Redirector), so it may be practical for you to do in practice. However, you need to worry about man-in-the-middle attackers... > 4) use DNS, have the client query > <repodata sha1sum>.repo.fedoraproject.org > if the lookup fails, the repo is invalid. (this is really cheap from a > resource standpoint, but hard to do technically) Same comment about man-in-the-middle attacks. DNS-cache poisoning trivially circumvents this protection... Thanks, Justin _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
