Joel++
Didn't know about that, very interesting. The tradeoff is not being able to use
newer versions of OpenSSL (and probably missing new features because of it).
De: Joel Maslak <jmas...@antelope.net>
Para: CPAN Testers Discuss <cpan-testers-discuss@perl.org>
Enviadas: Terça-feira, 11 de Outubro de 2016 13:36
Assunto: Re: Test system configurations
On Tue, Oct 11, 2016 at 9:39 AM, Timothe Litt <tlhack...@cpan.org> wrote:
On 11-Oct-16 11:14, Dan Collins wrote:
But other modules may work fine with these older versions of the library.
Yes, though versions with missing security patches seems like a very bad idea
for all concerned.
Are these Red Hat or CentOS machines? If so, having .9.8 versions don't
necessarily mean they have security bugs.
Red Hat Enterprise Linux has a philosophy of not changing the API of libraries
during the life of a major version. I.E. code that linked against libraries in
RHEL 5.0 should link against 5.8. They backport security patches from new
versions to the old version, but don't backport most features. Thus even
though RHEL 5 machines might be running ".9.8e" (hopefully -40), they will have
the critical security patches - even though OpenSSL officially doesn't have
them in .9.8e.
RHEL 5 will have end of production support by Red Hat on Mar 31, 2017.
Extended support is available until Nov 30, 2020.
As much as this sucks, I'd urge people to consider that RHEL is often chosen
because it has this incredibly long support with stable APIs, with Red Hat
backporting security fixes to those ancient versions of libraries. Basically
people use it because their binaries will work unchanged for 10+ years.
FWIW:
RHEL 5 will have .9.8e versions of OpenSSL with security patches backported if
people keep the box updated. Red Hat will support these machines until 2020.
RHEL 6 will have 1.0.1e versions and Red Hat will support these until sometime
after 2020 (probably +3 or +4 years after, at least).
