Random and rare Seg faults at openssl library level

[Jakob Bohm]

On 2021-01-07 18:05, Ken Goldman wrote:
> On 1/7/2021 10:11 AM, Michael Wojcik wrote:
>>>
>>> $ cat /etc/redhat-release && openssl version
>>> CentOS Linux release 7.9.2009 (Core)
>>> OpenSSL 1.0.2k-fips  26 Jan 2017
>>
>> Ugh. Well, OP should have made that clear in the original message.
>>
>> And this is one of the problems with using an OpenSSL supplied by the 
>> OS vendor.
>
> In defense of "the OS vendor", meaning the distro, it's a big task to
> upgrade to a new openssl major release.  Because there is often not ABI
> compatibility, every package has to be ported, built, and tested.
> A distro release that is in long term support doesn't do that often.
>
>

In defense of long term support distros, until a few years ago, no one 
suspected that OpenSSL would come under a new leadership that actively 
did everything to make it near-impossible to maintain backported 
security patches for a typical 5+ year distro lifecycle (with 
OpenSSL-independent start date).

Until 1.0.2, all OpenSSL releases were incremental patch-steps from the 
old 0.9.x series, allowing distro maintainers to manually cherry pick 
changes for doing ABI-compatible patches for whichever 1.0.x or 0.9.x 
was current at the start of their lifecycle.  Then the new leadership 
started to restructure the code even in supposedly patch-level releases.

A lot of long term support distros are now firmly stuck with unsupported 
OpenSSL 1.0.2 and/or short life cycle 1.1.1.

Not all long term distros are run by rich companies like IBM/RedHat that 
can purchase support plans, resulting in further popularity of OpenSSL 
forks.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded