On Fri, 2008-07-25 at 19:04 -0700, Justin Cappos wrote: > 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). And if that happens then it regets to another mirror and attempts to find a valid cert. Detached sigs is how it will be b/c otherwise we're breaking backward compat with older clients. And that's just chockful of pain. > > 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. And do what if they can't? think about it - at some point every repo will be 'too old' and then what? The client cannot use it at all? If that's the case then we're intentionally putting a sundown into our code, what a nightmare that is. The best we can do is warn and alert the user that the metadata is old. Stopping working is just preposterous - it's just a different kind of DoS if we do that. If the user cannot read and take warnings then there is really nothing that can be done for them. -sv _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
