Finding libssl on a customer's Linux

Question

We're using a library which needs to load libssl in a version 1.0.*. It doesn't work with libssl.so.1.1. We need it to work on any Linux system.

We try to load various versions and this usually works, but on system of one customer there's just the following:

/usr/lib64/libssl.so.1.1.0g
/usr/lib64/libssl.so.10
/usr/lib64/libssl.so.1.0.2m
/usr/lib64/libssl.so.1.1

We're trying to load libssl.so.1.0 and libssl.so.1.0.2, but it doesn't find libssl.so.1.0.2m because of the trailing "m".

I wonder what's the naming scheme of libssl, if any?

Do we really need to provide our own version or is there a better way?

Should we loop from libssl.so.1.0.2z down to libssl.so.1.0.2a? Should we scan the library path manually?

Solution

I'm not sure how you're opening libssl - I assume dlopen()?

Searching a hard-coded list of directory paths for a library sounds rather fragile - you'd be better off letting the dynamic linker do the work for you. Perhaps parsing the output of ldconfig -p is worth trying? On a Debian system, I see the following:

$ ldconfig -p|grep ssl
libssl.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl.so.1.0.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

On a RHEL 7.4 system:

$ ldconfig -p|grep ssl
libssl3.so (libc6,x86-64) => /lib64/libssl3.so
libssl.so.10 (libc6,x86-64) => /lib64/libssl.so.10

Note that on the Debian system the library is in /usr/lib/x86_64-linux-gnu, whereas on the RHEL system it's in /lib64 (also note the widely varying library names). Unless you use something like the output of ldconfig, you're going to have to search all of those distribution-specific paths yourself if you plan to "work on any Linux system". Admittedly, the directory paths are listed in /etc/ld.so.conf but I think using ldconfig is probably still easier.

Comments

[Rui F Ribeiro]

ln -s /usr/lib64/libssl.so.1.0.2m /usr/lib64/libssl.so.1.0.2 might work.

[maaartinus]

@RuiFRibeiro There are two problems with it: 1. Knowing the exact name. 2. It's a customer's computer.

[Rui F Ribeiro]

The bigger problem might be not having a test system then. Test the ln, is harmless and can be removed easily. See also @mjturner answer, it recalls important details.

[Andrew Henle]

How are you distributing your library? Don't try to find a compatible copy of OpenSSL on someone else's computer that you have no control over - bring the copy with you. The most reliable way is to distribute a known-compatible copy of the necessary OpenSSL libraries with your own library. Put the OpenSSL shared object(s) in the same directory as your library then find and dlopen() it, or statically link OpenSSL and build your shared object(s) so they incorporate the OpenSSL object files from the OpenSSL static libraries.

[Rui F Ribeiro]

I think the OP is not in Debian. +1

[maaartinus]

@RuiFRibeiro I was told, the problematic system is Fedora; anyway we need a solution for any Linux desktop . But ldconfig and/or /etc/ld.so.conf may be portable enough.

[Rui F Ribeiro]

I agree, that is why I voted you up.

[mjturner]

@RuiFRibeiro Indeed, but the same solution should apply. ldconfig -p should work on any Linux system (I've just confirmed and added some detail).

[Rui F Ribeiro]

You understand I just commented it was not Debian, right?

[mjturner]

@RuiFRibeiro I did :)