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-0001.sig>