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