Thanks Johnny for taking the time, it looks like the issue is much more convoluted than I initially assumed. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Johnny Hughes" <johnny at centos.org> > To: centos-devel at centos.org > Sent: Wednesday, 1 October, 2014 10:00:04 > Subject: Re: [CentOS-devel] yum-plugin-security and shellshock > 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: > > https://rhn.redhat.com/errata/RHSA-2014-1306.html > > 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 > there: > > https://rhn.redhat.com/errata/RHSA-2014-1311.html > > 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. > > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel