By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 2847

Summary:	tdelibs/tdeio cannot load OpenSSL on CentOS 7
Product:	TDE	Reporter:	Mihai Moldovan <ionic>
Component:	tdelibs	Assignee:	Timothy Pearson <kb9vqf>
Status:	NEW ---
Severity:	normal	CC:	bugwatch
Priority:	P5
Version:	R14.1.x [Trinity]
Hardware:	Other
OS:	Linux
Compiler Version:		TDE Version String:
Application Version:		Application Name:

Description Mihai Moldovan 2017-11-15 15:31:19 CST

Currently, tdelibs cannot load OpenSSL on CentOS 7 (this probably also affects CentOS 6, but I haven't tested on that platform.)

Note that I may not provide a patch, since my employer does not agree to sign your CLA. Hence, I create this bug report and give a verbal description of what needs to be changed and why this is necessary.

Within http://mirror.git.trinitydesktop.org/cgit/tdelibs/tree/tdeio/kssl/kopenssl.cc#n355 the library file names to be loaded are hardcoded.

The lists contain lib{ssl,crypto}.so.0, but CentOS 7 uses OpenSSL 1.0, which has a different suffix, namely lib{ssl,crypto}.so.10 as a minor-version-upgrade agnostic file symlink. Hence, I recommend adding the .10 suffix to both variables. This should fix the problem. Since tdelibs/tdeio also supports OpenSSL 1.1, I also recommend adding lib{ssl,crypto}.so.11 at the same time to be upwards-compatible.

The reason why Debian-based systems are not affected by this issue is that CentOS is doing stupid things in their OpenSSL builds. The above-mentioned list also includes "libssl.so." SHLIB_VERSION_NUMBER and SHLIB_VERSION_NUMBER should normally contain the shared library version number (that is *different* from the whole program number and stays stable for minor version upgrades, i.e., from 1.0.0a to 1.0.0b.) On Debian-based systems, that's true, i.e., SHLIB_VERSION_NUMBER is "1.0.0" for OpenSSL 1.0.0* and "1.1" for OpenSSL 1.1 - with the library files being installed with that suffix as well. Minor version upgrades do not break tdelibs/tdeio in that case.

However, CentOS is a special snowflake and patches the source code: https://git.centos.org/blob/rpms!openssl.git/c7/SPECS!openssl.spec#L222

What this innocent-looking sed call does is setting SHLIB_VERSION_NUMBER to the full version number, for instance "1.0.0k". If tdelibs/tdeio is compiled, it'll work... until the system OpenSSL version is updated to 1.0.0m, after which it'll be unable to access the old lib{ssl,crypto}.so.1.0.0k files. This is what currently happened. The tdelibs package was built against an older OpenSSL version then currently available in the CentOS repository.

Mihai