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.