[CentOS-devel] yum-security and CentOS-5 / 6

[Baptiste AGASSE]

Hi,

Thanks you to plan to work on this point. If you need some help to implement it, maybe i could help (for example on spacewalk integration part).

> 
> with a bit of time opening up, I've gone back to looking at the
> yum-security issue and how we can address it ( i.e: atleast get the
> basics working ).
> 
> I plan on doing the work in multiple stages as :
> 
> step1: get a basic set of metadata online so that people can detect if
> an update is tag'd security, bugfix or enhancement

That's a good starting point.

> 
> step2: get some more metadata added in, with bug id's and cve's into
> that metadata

I think this will be very useful (from my point of view) to track some clearly identified bugs or CVE that impact installed servers packages.

> 
> step3: get everything rolled out by default on all centos installs and
> look at how external projects like spacewalk/pulp etc consume this
> metadata

And this will be a "nice to have". We use spacewalk to manage our centos servers. some times ago we used centos-errata.py script (http://www.bioss.ac.uk/people/davidn/spacewalk-stuff/), but since centos project no longer provide md5sum for packages (and, as i know, spacewalk use it in packages storage tree)  it don't work any more.

> 
> 
> At the moment, I'm only thinking about things and trying to scope out
> the work. However, there is one issue that might be a spanner in the
> works based on how we have mirror.centos.org setup.
> 
> What we have right now only provides for the <version>.<release>
> rpmset
> and updates but only in relation to that specific tree (eg. /6.3/ is
> what /6/ maps to at the moment ). Yum-security metadata in this repo
> would then only be relevant to the rpms contained in /6.3/, whatever
> repo they might be in - however, someone running 6.0 or 6.1. when
> checking for updates is likely to miss interim updates that were
> security tag'd at some release level or the other.
> 
> One way to work around this would be to have yum consider all interim
> package metadata between installed.rpm and latest-in-repo.rpm ( which
> would then mean that we would need the yum-security metadata to
> contain
> all info for everything ever released ; isnt a problem as such ).
> 
> Or we setup a repo that has everything ever released. This in turn has
> some serious caveats. Storage on every mirror being a good problem to
> start with - however, in limited tests it looks like yum will work
> with
> redirect, so while we would need the metadata to contain all packages,
> the physical packages can still be handed out from vault.centos.org,
> but
> that redirect foo needs some level of smartness on the mirror end;
> trivial to implement when we control the mirror.centos.org network,
> however a very large part of the mirror services are offloaded to
> external mirrors - hundreds of them. Its super tricky getting
> smartness
> onto each and every one of their machines.
> 
> Thoughts, concerns, ideas ? There is no 'work' thats been done at this
> point on the problem, so we can take pretty much any course of action
> that seems sane.
> 
> I feel its important that if we are going to provide a mechanism that
> people will then in turn rely on to get patch requirements for their
> machines, we need to make sure we have 100% coverage.
> 

Have a nice day.

Regards.

Baptiste.