On Sat, 2008-07-26 at 13:06 -0400, Josh Bressers wrote:
This is of course a policy decision that can be dictated via a
configuration file.
But our default is what people will use which is what we need to get
straight.
There is also the issue of what happens when the
client keeps getting back "old" data? It need to go find some new data as
in our attack scenario, they are running something that needs updating. I
would think that the client should try some number of mirrors, if they all
return the same old data, it's probably EOL or something similar.
Except that if they are being given a single netblock mirror then
they're sol for finding another mirror.
If an
attacker has enough control over you to prevent you connecting to arbitrary
mirrors, you likely have bigger issues than this.
They can keep you from knowing about other mirrors, definitely.
Yes, I'm starting to think we should be having this discussion
with yum
upstream. Now that I have a grasp of what MirrorManager does, I don't
think there's really anything to fix there. We need to fix the client.
Unless throwing out warnings, errors and generally exploding when the
repodata is too old is good enough, I'm not sure how much more yum is
going to be able to do to alert the user that they are not getting any
updates applied. And we need to make sure to draw packagekit into this
discussion b/c they're going to need to honor the warnings, too.
If something is not broken but only 'worrisome' what is, from a security
standpoint, a good enough warning?
We can't seem to rely on users reading logs, or even reading dialog
output. At least that's what the gpg-key import discussion around PK
seemed to illustrate.
Seth, which list would you suggest to move this discussion so I can stop
pestering the infrastructure folks?
yum-devel(a)lists.linux.duke.edu, thanks,
-sv