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

Johnny Hughes johnny at centos.org
Wed Oct 1 09:00:04 UTC 2014

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.

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.

Meaning that (lets take CentOS-6 as an example) ... we would need a tree
of all RPMs (6.0, 6.1, 6.2, 6.3, 6.4, 6.5 .. plus all the updates
directories) on all the mirrors to make that work.

I suppose we could do it if all the metadata was in one place (at a
level up) and the directories could be separate.

But either way, it would add significantly to the size required to
mirror CentOS and require a redesign of how we do trees completely (we
currently only push the latest tree for each live major version).

(For example, we would likely have to separate ISOs out of main trees as
there is no way we could mirror all the ISO's as well as all the binary
RPMs for 11 CentOS 5 versions, 5 CentOS 6 versions, etc. to every
mirror, that is several TB of info if we include ISOs)


So, all of this would be required and the end result would be that you
would then be able to install security updates only.

The only problem with that is ... in a staged build system, security
updates only is not supported.  It is not really supported in RHEL
either.  Why do I say that?  Look at any RHEL RHSA update .. I'll take
one of the shellshock updates:


If you look at the Solution section you will see this quote:

"Before applying this update, make sure all previously released errata
relevant to your system have been applied."

It does not say all "previously release Security Errata" has been
applied ... it does not say all "BugFix and Security Errata" has been
applied .. it says "all previously released Errata" has been applied.

Why is that?

Well, because things are built on top of the last update (the build root
used is 'staged').  The build root grows as you add packages to the
distribution.  Package A is built, it goes into the build root and then
Package B gets built the next day against that Package A.  If you run
that Package B against an older version of Package A than the one it was
built against, then it may not work the same way as it was intended to work.

So, the only 'supported' and 'tested' configuration is all the latest
packages installed.

That is why Red Hat specifically has EUS/AUS repositories where they
SPECIFICALLY built the same bash (in our example) against the extended
6.4 EUS tree.  They have a different shell shock patched build of bash


The bash for RHEL-6.4 AUS is (after being built against the 6.4 AUS
tree) different that the one for RHEL-6.5 .. why is that?  Because it is
the same source code, but it is built against a different subset of
packages.  (The AUS is basically all of 6.4 as it was when 6.5 was
released, and all the new 6.5 security updates, built in order and in a
staged manner against that 6.4 tree ... so it is '6.4 plus 6.5 security
updates'.) Do you think Red Hat would maintain a separate AUS/EUS 6.4
tree and build all the new security updates from 6.5 again against that
6.4 EUS/AUS tree if the users could just not update to 6.5 and just use
yum-security to use the 6.5 updates?  Of course not, they would just use
the 6.5 security packages for 6.4. They don't use the 6.5 security
updates directly against 6.4, because it might not work.  Instead, they
maintain a separate 6.4 tree.

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.


So, only installing Security updates and not all updates is not a very
good idea (certainly on on different minor versions), because you are
not operating in a tested manner and the update could very well not even
mitigate the security issue UNLESS you install all updates (security and
otherwise) that happen before it anyway.

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?

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20141001/93dba8da/attachment.sig>

More information about the CentOS-devel mailing list