[CentOS-devel] yum-security and CentOS-5 / 6
mail-lists at karan.org
Wed Aug 8 10:08:03 UTC 2012
On 08/02/2012 12:54 PM, Andreas Rogge wrote:
>> 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.
interesting. are you saying that most people are not interested in
tracking specific CVE's etc ?
>> 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.
problem with the new layout is that every mirror will now need ~ 1TiB of
storage ( compared with the ~ 80 GB needed now ); with hardlinking
aggressively, we could bring that down to about 600GB or so, but its
still way too much.
Lets only consider doing that if there is realistically no way to fix
the problem without making that big a change to mirroring requirements.
The other option we have is that yum-security would need to rely on
centos-release-extras, which in turn can ship a CentOS-Vault repo, with
the relevant metadata included from vault. The only change that would
need is that vault.centos.org needs to not only contain older packages,
but also ones from the present tree.
There is no way to really tell, but I feel uptake for yum-security is
going to be a small number of people across all CentOS users - and we
might be able to satisfy demand with a reasonable performance level by
adding a few more machines to Vault.centos.org rather than changing
mirror.centos.org and all the external mirrors.
> 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.
right, thats the point - to make yum-security worthwhile, it needs to
not consider point releases, the whole distro ver needs to be considered
in one stack.
> 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.
the plan is to have the generation code hard wired into the script which
pushes rpms to the updates/ repo. that should mostly solve the problem
going forward; for retrospective updates and for rpms released into the
base os at point release time, i think it will haveto be a manual effort
for now. Maybe we can try and get some level of smartness sorted for 6.4
and beyond, but for now it will need to be a manual effort ( which I am
trying to reduce as much as possible ).
> Upstream has a release-number on their errata and we should probably
> also introduce one.
as far as I can tell that -<release> for errata is to handle internal RH
oops' rather than something that is exported publicly. Once something is
marked as public, they dont increment the release number, which is good.
The only exception I have seen to that is when they update releaes to
change grammar or text within a release announcement. A real fix or
change to the packages would have to be via a new errata notice.
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc
More information about the CentOS-devel