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.