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.