On 11-Oct-16 12:36, Joel Maslak wrote: > On Tue, Oct 11, 2016 at 9:39 AM, Timothe Litt <tlhack...@cpan.org > <mailto: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. I've seen failures on windows (XP) and debian - but that's just what the first few testers happened to run.
What I did was to report the result of 'openssl version', then run my tests. And there is one that fails on some machines; and when it does, the version is always 0.9.8*. I suspect it's a missing or broken feature, but as the module that directly calls OpenSSL isn't mine, it would be a lot of trouble to find out. I do know about the backports' dishonest versions, and agree that the version isn't definitive. However, every failure has been with old OpenSSL. It's also hard to keep track of the multiple branches even if the distribution updates the version. So version # isn't a sensible test. I've decided to have Makefile.PL try the operation that was reported and refuse to generate & unlink the Makefile if fails. It's not clear if I should go for a NA (platform not supported) or DISCARD (test didn't run). NA would give me some indication of failures without discouraging potential users. DISCARD would be more accurate - and avoid noise in the stats. What are the conventions for using these codes? > > 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). >
smime.p7s
Description: S/MIME Cryptographic Signature
