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

Thu Aug 2 11:54:08 UTC 2012
Andreas Rogge <a.rogge at solvention.de>

Am 01.08.2012 18:49, schrieb Karanbir Singh:
> hi Guys,
> 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 ).

Thank you so much for starting this effort!

> 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 probably what 90% of people will be happy with.

> 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.

Probably. But that's an issue with the mirror- and repository-layout. 
The solution to this is having one continous updates-repository per 
distro-version instead of one per point-release.

So we would have:
to contain all update-rpms for all point-releases and the rpms released 
at point releases.
Additionally you would place symlinks for isos and os to point to the 
last point-release directory

And the point-release directories would boil down to:
to contain the installation media and mayve a set of symlinks pointing 
to the repos in /6/

If splitting like that it is quite simple:
You add updateinfo.xml to all repositories below /6/ and make the 
listing of all contained rpms in updateinfo.xml a requirement.
For the point releases you don't want or need any updateinfo.xml as 
anaconda doesn't support updateinfo.xml and the repository will only be 
used for installs and not for updates.

> 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 ).

I'd just go down that road. I wouldn't even make a difference for 
architectures and you can argue wether it is worth the effort to 
differenciate between major releases.

In fact you can probably put the complete updateinfo into every base and 
updates repository without messing anything up. Without messing around 
with the overall mirror- and repository-layout this is probably the 
easiest way to handle it.

If we kept the updateinfo in a database or something else that 
searchable and machine readable in an efficient manner one could also 
generate an accurate updateinfo.xml for every repository.
This would also make testing much easier: if you want to test stuff, you 
can simply generate your own updateinfo.xml for your own local mirror by 
querying the database using a custom query.

> 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.
Coverage is important, but it is rather simple to test: just make sure 
every package in you repo is mentioned in updateinfo.xml. Maybe throw in 
a blacklist with the packages from the x.0-release.
What is much harder to achieve is reliability and consistency of the 
information provided.

Upstream has a release-number on their errata and we should probably 
also introduce one.
Additionally we will want another centos-own numbering scheme for 
updates that do not duplicate upstream errata (i.e. stuff that goes to 
extras or centosplus).

Scenario 1:
Sometimes you will have to change errata that were already released. Say 
you have CESA-2012:123 that fixes a flaw in a a package contained in 
CentOS 5, CentOS 6 and the upcoming CentOS 7.
As CentOS 7 is not yet done, we push out the errata for CentOS 5 and 6. 
This is "CESA-2012:123-1".
Once CentOS 7 is done, the update would be release for CentOS 7, too. 
This requires a change to the already release errata, so its version 
should be increased to "CESA-2012:123-2".

Scenario 2:
You build the packages for CEEA-2012:456 and push them to the mirrors. 
By doing that CEEA-2012:456-1 is released.
However, you realize that you really broke stuff and you have to push 
fixed packages immediately. As you changed a released errata, you have 
to change its version making it CEEA-2012:456-2

Solvention Ltd. & Co. KG
St.-Sebastianus-Str. 5
51147 Köln

Tel: +49 2203 989967-0
Fax: +49 2203 989967-9

mailto:info at solvention.de