On 15 May, Roger Marquis wrote:> Mark Felder wrote:
>>> Another option is a second openssl port, one that overwrites base
and
>>> guarantees compatibility with RELEASE. Then we could at least have
all
>>> versions of openssl in vuln.xml (not that that's been a
reliable
>>> indicator of security of late).
>>>
>>
>> This will never work. You can't guarantee compatibility with
RELEASE and
>> upgrade it too.
>
> How do you figure? RedHat does exactly that with every backport, and
> they do it for the life of a release.
They have paying customers to cover the cost of the salaries of the Red
Hat employees who backport security fixes to whatever version of
software that they included in the initial release if it has been
abandoned by its upstream source. Don't expect any new features,
though.
According to <https://access.redhat.com/support/policy/updates/errata/>,
RHEL 4 is supported through March 2017 and RHEL 5 is supported through
November 2020, though both are now in the extended lifecycle support
phase, which is an "add on" and probably costs an extra leg. RHEL 4
uses openssl 0.9.7 and RHEL 5 uses openssl 0.9.8. According to
<http://en.wikipedia.org/wiki/OpenSSL>, upstream support for the former
ended in February 2007 and the latter will end at the end of 2015.
Neither support TLS v1.1 or v1.2. If you need that and you are stuck on
one of these versions of RHEL, you are on your own and have to wedge a
newer version into the system yourself by downloading the source,
running configure and make, and installing under /usr/local. Then you
need to build whatever needs the new openssl yourself, making sure that
it picks up the right version. No shiny RPMs for you!
I used to run CentOS 4 (RHEL 4 clone) at a previous job. It came with
an ancient version of gcc that wasn't capable of compling some other
piece of software that I needed. I needed to wedge in a recent version
of gcc, binutils, and a bunch of other dependencies before I could even
get around to building the software package that actually needed.