Red Hat Bugzilla – Bug 1277662
Question regarding the relevance of the custom soname for openssl libraries in >= 1.0.0 versions
Last modified: 2015-11-04 03:11:42 EST
Due to apparent historical reasons, Fedora uses a different soname for the openssl libraries (libssl and libcrypto) than the one defined upstream .
From what I understood this might have been needed for pre-1.0.0 versions due to functionalities that had to be stripped due to patent issues.
I'm not competent enough to say if this custom soname is still relevant API-wise, but since most other GNU/Linux distros do not change this soname, it introduces compatibility issues for binaries dynamically linked against openssl on a non-Fedora system when trying to run them on Fedora (see e.g.  or one of the various forum topics telling Fedora users to make symlinks), since distros like Debian, Ubuntu or Mageia link against libssl.so.1.0.0 and libcrypto.so.1.0.0, while Fedora provides .so.10.
So I just wanted to question the current relevance of this custom soname, to see if Fedora could go in a more upstream-compatible direction (or have the soname changed upstream if need be).
Thanks in advance.
There is no ABI compatibility among OpenSSL in various distributions unless they really care about it and keep the patches and enabled/disabled feature sets of OpenSSL exactly the same. I did not look at the other distros in depth but I do not expect them to carry the same stuff as we do in for example the FIPS support patches, etc. So the non-upstream soname is still very much relevant for Fedora. I might look at the issue again once we will be rebasing to the current upstream master branch (i.e. openssl-1.1.0) as that version will break ABI again.