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

Nico Kadel-Garcia nkadel at gmail.com
Fri Oct 3 03:22:32 UTC 2014

On Thu, Oct 2, 2014 at 3:00 PM, Les Mikesell <lesmikesell at gmail.com> wrote:
> On Thu, Oct 2, 2014 at 1:28 PM, Pat Riehecky <riehecky at fnal.gov> wrote:
>> On 10/02/2014 12:31 PM, Karanbir Singh wrote:
>>> On 10/02/2014 06:00 PM, Pat Riehecky wrote:
>>>> We were fully aware of which versions of openssl contained CVE-2014-0160
>>>> and which SL versions contained the vulnerability.
>>> excellent, but you completely missed the point where all of SL installs
>>> were potentially at risk, with no way to factor back or check any state
>>> since there is no CVE validation being done.
>>> or are you doing cve validations and testing expoits actively now ?
>> The CentOS Devel list seems to be the incorrect place to debate SL update
>> policies.
> If you look at in the context of improving the systems and which
> serves the users needs best, then the more information the better.
> Do you have some examples of things that have broken on full minor-rev
> updates?

I personally work extensively with both. The underlying distinction is
that the CentOS takes its old releases effectively offline,
transferring them to the 'CentOS-Vault' repository where access to the
out of date material requires additional steps. As such, it's
vulnerable to some though not all of the "only update these
components" issues. The lack of default access after a new minor
release, such as CentOS 6.1 being in the vault by the time CentOS 6.5
was published, means that installations of one update such as openssl
may trigger a host of other unexpected updates. The same is true for
package installations without enabling the "CentOS-Vault". If I
install openjdk later on on a CentOS 6.1 system, I get the CentOS 6.5
published openjdk. And I don't necessarily *want* to automatically get
the latest revision with all its dependencies, I may want the same
version as was available when I installed the system. It's workable as
is, but takes some extra steps.

Worse: If I do "yum list extras" on a locked down CentOS system, one
that has not been updated frequently, I get an enormous list of
"extras" that are not accessible in the now active repositories. It
gets quite confusing if you'e not paid attention to the layouts and
update practices and needs to enable 'CentOS-Vault'. This can be
chaotic for system consistency, and I'm personally dealing with some
aspects of this right now.

The Scientific Linux layout segregates the "deployed OS" and keeps it
available in the active yum mirrors, as "6.1", "6.2", etc.  "Updates"
seem to be locked, after an OS minor revision is update, at the state
when the next minor revision occurred. The leading edge *is*
available, in the "6x" repository, for those who elect to remain
bleeding edge. And it can be enabled on a case by case basis. This is
much closer to how Red Hat used to publish minor releases, with the
exception that now there is always a "5x", "6x", "7x", etc. link to
the latest minor release.

This makes keeping an internal mirror of the current and previous
minor releases much easier, and it's not that much of a loss in
repository efficiency as long as 'rsync' is used with the '-a --delete
-H' options, with '-H' preserving hardlinks. It also makes updating to
the full new release easier: I can do "yum install yum-conf-6x" to
enable access to the current repo, and "yum delete yum-conf-6x" to
lock it back down to the installed release.

I'm not judging either as the only way to do things: I'll admit that
I've found Scientific Linux's approach to be helpful for full
"bill-of-materials" stability.

More information about the CentOS-devel mailing list