On Wed, Oct 1, 2014 at 4:00 AM, Johnny Hughes johnny@centos.org wrote:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
It does not say all "previously release Security Errata" has been applied ... it does not say all "BugFix and Security Errata" has been applied .. it says "all previously released Errata" has been applied.
Why is that?
Well, because things are built on top of the last update (the build root used is 'staged'). The build root grows as you add packages to the distribution. Package A is built, it goes into the build root and then Package B gets built the next day against that Package A. If you run that Package B against an older version of Package A than the one it was built against, then it may not work the same way as it was intended to work.
But, you have to consider it a bug against the 'stable API' concept of an enterprise distribution release if that api is broken, whether is it for user, third-party, or internal code.
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
You've done a good job of describing the theory here. Now what about the practice on the consuming side? When you know you have an installed package with a known security vulnerability do you (a) ignore it, (b) install the one fixed package that hasn't been tested with the others, or (c) install a whole bunch of new code that hasn't been tested together with your third party and local packages?
Or should we maintain our own build environment matching current installations and rebuild source rpms individually as updates for them? None of these are going to be ideal, but neither is waiting to complete full-blown testing of a complex system before fixing a security issue. Just looking for expert opinions on the risks...