[CentOS-devel] yum-security and CentOS-5 / 6
a.rogge at solvention.de
Thu Aug 2 11:54:08 UTC 2012
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
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).
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".
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
Tel: +49 2203 989967-0
Fax: +49 2203 989967-9
mailto:info at solvention.de
More information about the CentOS-devel