YUM security issues...

[seth vidal]

On Fri, 2008-07-25 at 18:41 -0700, Toshio Kuratomi wrote:

> > 3) Always get repo data from fedoraproject.org (probably not practical due
> >     to resource issues)
> This is the easiest to implement.  It means the small repomd.xml file 
> always comes from our server.  But the rest of the metadata can come 
> from the individual mirrors.  However, it does mean that *very* large 
> swaths of the mirrors will be unable to serve packages to users at any 
> time because their metadata won't match with ours for some period after 
> we have an update pushed.  Maybe we could do this with versioned 
> repodata and the client can decide how far back in time or how many past 
> revisions it is willing to accept.

We don't need to version the metadata, we have timestamps in them
already.

We can easily do a comparison from this timestamp to now. And we can set
this number to be different from the base repo as to the updates repo.

 But as you've already mentioned we're stuck with the question of EOL'd
releases and how to deal with things deeply out of date.

I can make yum throw out warnings and alerts but at what point does it
actually STOP doing anything and does that not open us up to a different
kind of DoS?


> I don't know enough about implementing this one to comment.
> 
> Also, all of these solutions need client-side support.  That being the 
> case, it should be generic enough that other repomd consuming clients 
> and distributions will be willing to use it.  Otherwise we'll be 
> securing our updates and mirror infrastructure with the default package 
> manager but doing nothing for the ecosystem as a whole.

We need to make sure that whatever we implement is trivially done so by
people running a local downstream branch of fedora or centos or
what-have-you. Or, as you say, we've saved ourselves and screwed
everyone else.

-sv