Thanks for the helpful replies. Guess I'll build it myself.

On Wed, Mar 5, 2014 at 2:38 PM, Dennis Jacobfeuerborn <dennisml@conversis.de

wrote:

On 05.03.2014 22:19, Michael Coffman wrote:

...

I am running centos6.4. Where do I find the updated gnutls packages?

I

...

see the updated source file here: http://vault.centos.org/6.5/updates/Source/SPackages/

But I don't see the correct version of the packages in the 6.4 tree here: http://vault.centos.org/6.4/updates/x86_64/Packages/

Where should I be looking for the updated package for 6.4?

There never will be any. 6.4 and 6.5 are not independent installations of the system and you simply have to upgrade to 6.5 to get fixes.

Regards, Dennis

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Not sure what your environment looks like but the systems I manage are locked down and it's typically difficult to get them changed. We have hundreds of systems ( desktop, server and HPC systems) that are all the same rev with all the same packages. A large number of vendor packages and internally developed packages have to be re-qualified everytime anything is changed. So we don't change them often.

On Wed, Mar 5, 2014 at 4:26 PM, John R Pierce pierce@hogranch.com wrote:

On 3/5/2014 3:22 PM, Michael Coffman wrote:

...

Thanks for the helpful replies. Guess I'll build it myself.

what? why???

yum update gnutls

*done*

-- john r pierce 37N 122W somewhere on the middle of the left coast

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Wed, Mar 5, 2014 at 4:44 PM, John R Pierce pierce@hogranch.com wrote:

On 3/5/2014 3:36 PM, Michael Coffman wrote:

...

Not sure what your environment looks like but the systems I manage are locked down and it's typically difficult to get them changed. We have hundreds of systems ( desktop, server and HPC systems) that are all the same rev with all the same packages. A large number of vendor packages and internally developed packages have to be re-qualified everytime anything is changed. So we don't change them often.

so you're a year behind on any security fixes.... why are you worried about this one, then?

This seems like it has more potentiol to impact users in my environment that are using a web browser to access sites outside our firewall. It seemed like a reasonable question to me as it looke like it might be easily updated. I did not realize that once the OS was vaulted, there were no more updates. Now I know so thanks...

-- john r pierce 37N 122W somewhere on the middle of the left coast

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Wed, Mar 05, 2014 at 06:12:49PM -0600, Les Mikesell wrote:

On Wed, Mar 5, 2014 at 6:00 PM, Michael Coffman

...

updated. I did not realize that once the OS was vaulted, there were no more updates. Now I know so thanks...

No, what everyone has said is that there _are_ updates, and yum knows how to get them, even selectively.

More to the point, "6.4" and "6.5" are just markers in the sand for "CentOS 6". 6.5 is basically just a rebasing of the packages to make it easier to install; it's an accumulation of updates for 6.4 in an easy to digest form.

If you stop thinking of "6.4" and "6.5" as different OS's but as the same OS but at different parts of their patch lifecycle then it becomes a lot simpler.

On Wed, Mar 5, 2014 at 6:43 PM, Stephen Harris lists@spuddy.org wrote:

...

No, what everyone has said is that there _are_ updates, and yum knows how to get them, even selectively.

More to the point, "6.4" and "6.5" are just markers in the sand for "CentOS 6". 6.5 is basically just a rebasing of the packages to make it easier to install; it's an accumulation of updates for 6.4 in an easy to digest form.

If you stop thinking of "6.4" and "6.5" as different OS's but as the same OS but at different parts of their patch lifecycle then it becomes a lot simpler.

I think it is really just a quirk of centos package management where to be kind to the repository mirror sites they rebase what the repositories hold to be just the newest at each minor release (since that is what a yum update will pull anyway). That way the mirrors don't have to hold all of the old/intermediate package versions that are only kept in the vault repository. It is pretty much irrelevant to normal updates - you can update from any version to current, even just with specific packages.

On 03/06/2014 12:27 PM, Cliff Pratt wrote:

I have some sympathy for Michael. There are organisations which are so paranoid that they will not allow updates between eg 6.4 and 6.5, either because they insist on rigorous (ie lengthy and time consuming) regression testing of applications or because a third party package vendor specifies a particular level of OS for their product (I can think of at least two).

It is very unfortunate that many organisations and vendors put up restrictions without examining the technical details of specific environments, thus treating 6.4 and 6.5 like separate OS-es. The restrictions are put up with the intention of protecting the environment from getting broken by incompatibility that may be brought in by new packages, but the irony is that by sticking to these restrictions, they are broken already with respect to bug fixes and security fixes available with updates not being applied. They need to be educated that API and ABI compatibility will not be broken across minor releases of a single major version. It is essentially a confusion between update and upgrade, I feel.

- rejy (rmc)

Les Mikesell wrote:

On Thu, Mar 6, 2014 at 12:57 AM, Cliff Pratt enkiduonthenet@gmail.com wrote:

...

I have some sympathy for Michael. There are organisations which are so paranoid that they will not allow updates between eg 6.4 and 6.5, either because they insist on rigorous (ie lengthy and time consuming) regression testing of applications or because a third party package vendor specifies a particular level of OS for their product (I can think of at

least two).

...

Who has not been caught in the "not supported here" trap? You install a package from the OS supplier, and have an issue with it. You go to the forum for the package and get the response "upgrade to the latest release", but the OS supplier will not support the OS if you upgrade

the package

...

to the latest release!

A strict requirement based on arbitrary version numbers may be foolish, but a requirement for thorough testing before any change to a production environment is not - even though the changes that happen through the minor releases of an 'enterprise' OS have already been vetted for changes to existing APIs. However, you really have to assume that whatever you are running has security flaws and you have to be prepared to roll out the fixes as soon as possible after they are released since at that point the vulnerabilities will be well known. So, you need a fairly agile testing/deployment process to match your policy and keep it from doing more harm than good.

As the guy who does that here, what I do is to 0) arrange a monthly maintenance window (saves a *lot* of pleading and begging) 1) update the development system (or, in some cases, they prefer that I update the test system, making regression easier). 2) update the other (test or dev). 3) if everything looks ok, update the backup prod machine, for those that have them 4) finally, in the prearranged window, so that users know what's happening, update the prod machines and reboot.

I'd have to think long and hard to *ever* needing to downgrade a prod server.

mark

On Wed, Mar 5, 2014 at 10:01 PM, Bart Schaefer barton.schaefer@gmail.com wrote:

Before you update anything, I suggest you run

rpm -e --test gnutls

If this complains about "refers to more than one package" then use

rpm -e --test gnutls.i386 gnutls.x86_64

This will tell you what other packages depend on the gnutls library. It's probably fewer than you think, because RHEL/CentOS have openssl packages as well. We determined that for our servers we could simply remove gnutls (desktops are a different matter).

(Ideally "rpm -q --whatrequires" would tell you this, but in fact it does not unless you know the magic string that fully names "libgnutls.so...")

Wouldn't 'yum remove gnutls' be a better check since it will walk up the dependency tree - and is interactive by default so it will show the list and wait for confirmation?

Am 06.03.2014 um 01:00 schrieb Michael Coffman michael.coffman@avagotech.com:

On Wed, Mar 5, 2014 at 4:44 PM, John R Pierce pierce@hogranch.com wrote:

...

On 3/5/2014 3:36 PM, Michael Coffman wrote:

...

Not sure what your environment looks like but the systems I manage are locked down and it's typically difficult to get them changed. We have hundreds of systems ( desktop, server and HPC systems) that are all the same rev with all the same packages. A large number of vendor packages and internally developed packages have to be re-qualified everytime anything is changed. So we don't change them often.

so you're a year behind on any security fixes.... why are you worried about this one, then?

This seems like it has more potentiol to impact users in my environment that are using a web browser to access sites outside our firewall. It seemed like a reasonable question to me as it looke like it might be easily updated. I did not realize that once the OS was vaulted, there were no more updates. Now I know so thanks...

The OS is not vaulted. I suggest to rethink the mental model of the OS point releases.

IMHO the above mentioned policy brings less security into the organization then it tries to suggest and do not forget that the most attacks came from internal.

There are more fixes to worry about

https://rhn.redhat.com/errata/rhel-server-6-errata.html

-- LF

On 03/05/2014 06:36 PM, Michael Coffman wrote:

Not sure what your environment looks like but the systems I manage are locked down and it's typically difficult to get them changed. We have hundreds of systems ( desktop, server and HPC systems) that are all the same rev with all the same packages. A large number of vendor packages and internally developed packages have to be re-qualified everytime anything is changed. So we don't change them often.

Scientific Linux will allow you to stay at a particular update rev (6.0 if you had that requirement, even) but still get security updates. So you might consider installing the gnutls update from the SL 6.4 updates instead, or rebasing to SL completely.

This is one of the few really significant differences between SL and CentOS; the SL user base wants to be able to get security updates without a complete 'point release' update, too, and have put forth the nontrivial effort required to actually make that happen.

I'm using CentOS myself, but if you need that particular feature of SL it may be the better choice for you.

On 03/07/2014 11:57 AM, m.roth@5-cent.us wrote:

Lamar Owen wrote:

...

I'm using CentOS myself, but if you need that particular feature of SL it may be the better choice for you.

Have you used yum-plugin-security?

Why yes, yes I have. It is not equivalent to the SL versioning for the particular use cases and scenarios for which the SL versioning method was made. By your response you indicate that you really don't understand what SL is actually doing. It's going one step beyond what upstream is doing and adding a feature that some people and institutions vastly prefer.

No, I am not advocating that this is the 'one true way' to do it; I'm pointing the OP to something that was designed for a scenario much like the OP's specific situation.

On Wed, Mar 5, 2014 at 5:22 PM, Michael Coffman michael.coffman@avagotech.com wrote:

Thanks for the helpful replies. Guess I'll build it myself.

Why? 'yum update gnutls' will get it, bringing along only things specified as having version-specific dependencies if there are any. But it is generally a bad idea to let the rest of your system get out of date. Is there some reason you can't do a full 'yum update' to pick up the rest of the fixes?