On 07/30/2015 04:37 AM, Johnny Hughes wrote: > On 07/29/2015 07:27 PM, Nathan Duehr wrote: >>> >>> On Jul 29, 2015, at 18:20, Nathan Duehr <denverpilot at me.com> wrote: >>> >>>> On Jul 28, 2015, at 18:48, Peter <peter at pajamian.dhs.org> wrote: >>>> >>>> On 07/29/2015 11:51 AM, Noam Bernstein wrote: >>>>> Hi CentOS developers - I’ve been happily using CentOS for several >>>>> years now, so thanks for all the good work. In the last week, >>>>> however, I noticed that while the items in RHSA-2015:1443 has shown >>>>> up as updates (and announced on centos-announce), the analogous >>>>> update for CentOS 6, RHSA-2015:1471 (according to >>>>> https://access.redhat.com/security/cve/CVE-2015-4620), doesn’t seem >>>>> to be there. Is there any reason why those of us using CentOS 6 are >>>>> left behind, and/or any idea when a CentOS 6 bind update will be >>>>> available? >>>> >>>> It's currently in the CentOS CR repository and will be released when >>>> CentOS 6.7 drops soon. If you want it now then just enable cr and >>>> you'll get it with yum update: >>>> http://wiki.centos.org/AdditionalResources/Repositories/CR >>> >>> Why didn’t it just go into CentOS 6.6 like a dozen other packages this week? >> >> Disregard, I guess for whatever reason when a new dot-release is going on, things go into CR, but otherwise they go into the dot-release. Or so I just read in the notes about the current repo state. >> >> Yay, another goofy annoying thing to remember and another thing to go add to ansible code to deploy and undeploy this goofy CR repo, just to check machines properly for security updates. >> >> Not that I don’t love ya, volunteers, but I really hate waiting on security updates while they bounce through CR… that doesn’t make any sense at all. Bug fixes, sure… security, no. >> > > Of course it makes sense. Those security updates are not released in a > vacuum, and all the things they are built on/against also need to be > released and installed for them to work. > > The source code for the ssecurity updates you are talking about are > built against RHEL-6.7, not 6.6 by Red Hat. They don't necessarily work > on 6.6 without the other updates installed. They also will not > necessarily work correctly if built against 6.6 and then used later on > 6.7. We don't do this because it is fun. In fact, it is exact opposite > of fun, it is quite a PITA. We do it because in order to run the > updates (and have them work correctly), you also have to be running the > rest of 6.7. > > We are providing CR .. SO .. you can get all the updates if you want > them early .. WHILE .. we also test and release 6.7. It is double the > work. > > Because we do CR, CentOS users had access to the 6.7 updates a full 3 > days before anyone else made them available and CR was released less > than 5 days after the release of RHEL 6.7. > For those interested, here is a bit longer explanation: When you build C (the language) programs on GNU/Linux, the vast majority of programs on CentOS or any other Linux distro are C or C++, you use a compiler called gcc and run against a standard c library called glibc. The gcc and glibc packages are updated almost every point release in CentOS. Also, most programs have other "Build Requirements" where they build against other other "devel" packages as well. A "devel" has headers that reference libraries and one program "links" against another program and uses that other program's libraries in order to run. I will use a build in the latest CentOS-7 tree as all our build logs for CentOS-7 are public. Let us look at build of the package ipa-4.1.0-18.el7.centos.3.x86_64.rpm. It was built on timestamp 20150326124151 (March 26th, 2015 at 12:41:51 UTC), and the logs can be found here: http://buildlogs.centos.org/c7.01.u/ipa/20150326124151/4.1.0-18.el7.centos.3.x86_64/root.log If you look at the root.log file, you will see a group of files starting with bash after a line: DEBUG util.py:282: Installing: That is the 24 packages CentOS Linux uses to create our x86_64 build root. Those 24 packages "bring in" another group of packages and there are 153 total packages in the build root. You can see the versions of each of those packages in the root log. The only 'devel' packages in the generic build root are glibc-devel (part of the gcc source) and libstdc++-devel (part of gcc source). The gcc package is 4.8.3-9.el7 and the glibc package is 2.17-78.el7. If using older gcc or glibc packages, it is possible to have issues calling something that does not exist. That means this is ipa package is only TESTED to run on gcc and glibc higher than 4.8.3-9.el7 and 2.17-78.el7. If you use older ones, there could be issues. So, this package should be used with only CentOS version 7.1.1503 or newer as those versions of glibc and gcc were introduced at that point. (Note: newer versions of gcc and glibc are normally compatible, older versions may or may not be, hence newer than 7.1.1503 should always work correctly, older maybe not). Now, lets look at the 'build requirements' that ipa brings in. If you find another line called: DEBUG util.py:282: Installing: With 389-ds-base-devel after it, you see that there are 53 specific requirements called out .. and you can see the versions that are used. Those 53 requirements pull in an additional 163 packages (216 total). You can see the versions of each of those packages in the root log. The ipa libraries could link against any of the 'devel' packages that are in the build root (I quickly counted 33 besides gcc and glibc). So, that means there are as many as 35 possible library dependencies that ipa has. Using this version of ipa with any of those dependencies earlier than the ones used to build it could cause issues. That is what every update that Red Hat puts out says this in the text (let's look at the release of Red Hat's same version of IPA): https://rhn.redhat.com/errata/RHSA-2015-0728.html Look at the 'Solution' section, it says this: * Before applying this update, make sure all previously released errata relevant to your system have been applied. * It does not say all security updates or all the cherry picked updates that you think you might want to install .. it says "all errata". All errata includes all Bug Fixes, all Enhancement Updates, all Security Updates that are applicable for the packages that you have installed. Is that "REALLY" necessary? Maybe. Running ipa without any of the updates used to build ipa "COULD" result in calls to things that don't exist. Could look in the shared libraries at different spots, call things in different ways, etc. That could introduce bugs that do not exist if all the updates are installed. Some of those newly introduced bugs COULD have security implications .. OR .. it might work fine with the older stuff. An in-depth analysis would be required to determine that. But that is why Red Hat says that you have to "make sure" to install "all previously released errata relevant to your system" when installing that version of ipa though. Because that group of packages is tested and it works. That is why I can't just cherry pick a bind update or a libuser update built on the CentOS-6.7 package set and release it in 6.6 or 6.5 or 6.4 .. it may or may not work and it may or may not be secure in that environment. Thanks, Johnny Hughes -------------- 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/attachments/20150730/72a27d7e/attachment-0005.sig>