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 - tdelibs/tdeio cannot load OpenSSL on CentOS 7
Summary: tdelibs/tdeio cannot load OpenSSL on CentOS 7
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: tdelibs (show other bugs)
Version: R14.1.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2017-11-15 15:31 CST by Mihai Moldovan
Modified: 2017-11-15 15:31 CST (History)
1 user (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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