[openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

[Wouter Verhelst]

On 28-05-17 23:51, Jeffrey Walton wrote:
> So what are the problems here that need to be addressed? I think I
> know some of them:
> 
>  1. Build OpenSSL with an RPATH if installed in non-system location
>  2. Build user program with an RPATH if OpenSSL installed in non-system location
>  3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends)

RPATHs have advantages, but they have some major issues, too. For
instance, if for whatever reason you need to move files around so that
things are stored in a different location, suddenly you'll need to
recompile everything -- because the RPATH is a hardcoded location of the
library in use. This is very confusing, and not something that an
average developer will expect.

There is usually no need to hardcode the location of the library in use,
provided the SONAME is configured correctly. Surprise surprise, OpenSSL
actually does that right:

wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
|grep SONAME
  SONAME               libssl.so.1.0.2
wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1
|grep SONAME
  SONAME               libssl.so.1.1

There is no way that ld.so will load libssl1.1 for an application that
is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless,
of course, you do things like muck about with RPATH and point it to the
wrong version of the library. In that case, you broke it, you get to
keep both pieces.

>  4. External build tools like Autotools and Cmake

Those are set up to assume that if a library has a particular SONAME, it
will be compatible with other versions of that same library. That's
usually the correct assumption.

Ignoring bugs in configure.ac/Makefile.am and/or CMakeLists.txt files
(those are just code too, you know), IME autotools and CMake usually
just DTRT, by simply using things like pkg-config to produce the correct
-I and/or -L search paths. If you insist on not using them though,
that's also possible:

%.o: %.c
	$(CC) -o $@ -c `pkg-config --cflags openssl` $^

target: foo.o bar.o baz.o
	$(CC) -o $@ `pkg-config --libs openssl` $^

The only reason why you would ever want to use RPATH with OpenSSL is
because you need to install a particular old version of libssl (or
libcrypto) that has the same SONAME as the system-default, but where you
don't want to use that system-default one -- but why would you want to
do that? Security updates are a good thing, usually.

RPATH support is nice for corner cases, but it should not be the
default, ever.

-- 
Wouter Verhelst