[CentOS-devel] yum-plugin-security and shellshock

[Kevin Stange]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/01/2014 04:00 AM, Johnny Hughes wrote:
> On 09/30/2014 11:10 AM, Kevin Stange wrote:
>> On 09/30/2014 10:03 AM, Nux! wrote:
>>> What needs to happen for that?
>>
>> We had a short discussion about it here:
>>
>> http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
>>
>> The issue is that something during the issuance of new updates has to
>> build a persistent list of CExAs and then regenerate the updateinfo.xml
>> while building the repo update.
>>
>> Right now CentOS pushes the update notices directly to the mailing list
>> and doesn't store that data anywhere to generate the XML file.  The only
>> way I know to build historical updateinfo.xml would be to scrape the
>> mailing list for all previous data.  Needed are release ID, package
>> (name, version, release, arch), SHA sum, release type (bug, enhancement,
>> new package, security), severity (if security), reference URL, summary,
>> additional description (if any).
>>
>> SL publishes updateinfo.xml so if someone has insight into how they
>> manage it, perhaps we could make use of the process to shoehorn into
>> CentOS. See:
>>
>> http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/security/repodata/updateinfo.xml
>>
> 
> I think that is only one issue.

All of these excuses below are FUD.

> The other issue (as I understand it), is that we would need an all
> encompassing metadata across all versions to make this work as well.

Just worry about what's on the mirror today and when a new package is
released, update the metadata for that one.

Why would you need metadata for packages that go back to before the
current release?  These updates are no longer available and new
installations are going to start at the current base.  You certainly
could match all the current in-tree packages to an errata release if
applicable and keep them in an updateinfo.xml in base.

As you go, keep all the advisories in a database of some kind, with all
the required data, such as ID number, package files, link to RHEL
errata, type of fix.  Then just generate the updateinfo.xml for all
applicable packages in the current repos (base AND updates) and leave
unknown packages out.

If you do that, then as time goes on, the errata coverage will fill in
over the life of the distribution.  For a while, only updates to the
most recent release(s) will be covered, which is going to be the bulk of
what people are installing anyway.  If you never start tracking this
information, you are staking a committment to ensuring there's never any
of this data, which doesn't make any sense.

If someone's installing a package for the first time, the errata isn't
really important.  It's only important when someone's looking to install
an updated version of something they already have.

In the case of Spacewalk, you start with the packages on the current
distro version and relevant errata.  As it updates packages, it keeps
the errata associations even if the package later moves from
5.10/updates to 5.11/base.  It also keeps all older packages in the
system, so that's not a burden that has to be placed on mirrors.

If someone really wants their spacewalk full of all packages ever
released for a distro, they can seed it back from the vault, but I doubt
very much that's something most people are looking for.

> So, all of this would be required and the end result would be that you
> would then be able to install security updates only.
> 
<snip>
> 
> If you take the 6.5 bash update and install it in 6.4, will it work?
> Likely.  Will it absolutely fix the security issue?  Maybe not .. it is
> certainly not 'supported' by Red Hat that way.

Well, in the bash case, yes, this update is self-contained and it will
fix the issue for any version of CentOS you install it on (that can run
it).  RH doesn't support that officially, but it'll be fine.

I know of ONE instance of cherry-picking a security update released by
CentOS that didn't work fine when all its dependencies were otherwise
met in the history of using CentOS.  It was an OpenSSL update that broke
compatibility if you didn't also update other packages, and it was
several years ago, in CentOS 4.

Your argument is beside the point though.  Even if cherry-picking is not
the recommended way to patch, the information doesn't have its sole
benefit in allowing people to do that.  With the right tools
(increasingly becoming default tools), users see classification of
packages and can more easily discover the errata without having to be
subscribed to centos-announce.

If you use the graphical updater in Fedora, you get a list of all
packages that have updates available matched with types of updates.
Fedora recommends installing them all, but it also triggers additional
urgency when one or more are security related.  It even triggers
reboot/logout recommendations if those are noted by the update info.
The yum plugin also lists the type of fixes when you run yum update, so
you can see the importance of doing an update ASAP.

> Therefore why would we want to take great pains to totally redesign our
> mirror infrastructure (the size increase rendering some number of our
> current donated mirrors as too small to now be used).  Take great pains
> to maintain a separate database of Security info to generate the xml
> file.  Then that will make the end release that it is now very easy for
> users to think they are safe (because they do all security updates after
> all) ... but they are not safe because they are running 6.5 security
> updates against 6.4?  Or help them run only critical security updates
> and the combination introduces new issues unique to that combination?

You don't have to do this.  Doing this would be a pain in the ass and
cause tons of problems for no reason.  This ask is for ONE TINY XML FILE
per repo.  That's all.  And it's probably not necessary for anything but
base and updates/ though I would recommend it for any repo that is ever
changed throughout a release lifecycle.

updateinfo.xml for base would be statically generated at initial release
with the errata known to map to current versions of packages being
shipped from previous releases of CentOS.  If this coverage starts out
at only a handful of packages, it's better than nothing.  If this is
really impossibly hard to do, then skip and just do updates/ to start
out.  Right now the only way is scraping the mailing list to get this
old data, but it's there for the taking.

> They only way to have another secure combination is to build and test
> the security updates in that combination.  If you want 6.3 with only the
> 6.4 and 6.5 Moderate Security updates (or above) added to that, you
> would need to build the 6.4 and 6.5 security updates (in order) against
> that 6.3 tree ... staging it as you go so that the next update gets
> built against the update before it.  You would also then need to TEST
> that this combination actually fixes the security issues.  Then you
> could be reasonably sure that the solution was safe.
> 
> But if you just installed the CentOS 6.4 and 6.5 moderate updates (or
> higher) on CentOS 6.3 (the same packages you rebuilt in the preceding
> paragraph) .. even if they installed, it would be significantly
> different than the solution where you built them yourself.

I don't think anyone has asked for this.  No one expects this in Fedora
or SL.  All I want is the metadata in the repo for the CURRENT packages
that are in the repo, so that when I import then into spacewalk or run
"yum update" I can easily pull up the information about those packages.

If an update occasionally is missing, it's not the end of the world.
Even 50% coverage is better than the 0% we have now, but getting 100% of
current updates/ repos and future releases is as simple as being willing
to just start storing the information and making generating the file
part of your release process.

SL has managed to figure out how to do this without mirrors having every
file ever released.  I'm sure CentOS has the ability to do so.

- -- 
Kevin Stange
Chief Technology Officer
Steadfast | http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQsNcYACgkQkd/BoeKjg0gF2gCfZxjeXO1aWDC9cLPGAYuUgjSI
y9sAn0HTBvy9B6yyfxyX0xfdKSMMT96o
=YMew
-----END PGP SIGNATURE-----