Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)
> 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@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 > |grep SONAME > SONAME libssl.so.1.0.2 > wouter@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. The OpenSSL I build from sources is located in /usr/local. The gear from /usr/local is first on-path. This is what happens on Ubuntu 16.10: $ /usr/bin/openssl errstr 0x3208408D /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version information available (required by /usr/bin/openssl) /usr/bin/openssl: relocation error: /usr/bin/openssl: symbol COMP_zlib_cleanup, version OPENSSL_1.0.0 not defined in file libcrypto.so.1.0.0 with link time reference This is what happens on Fedora release 25: $ /usr/bin/openssl errstr 0x3208408D error:3208408D:lib(50):func(132):reason(141) It seems to me SONAME's just don't work as expected. Jeff -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)
On 29/05/2017 16:39, Wouter Verhelst wrote: ... 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. There is another, converse case: If the system comes with a (patched) old version of the OpenSSL libraries (for example, Debian 7 comes with a patched OpenSSL 1.0.1 that ensures 100% compatibility with programs compiled against version 1.0.1t headers), then you may also need a special SO name or RPATH to link locally compiled software against the latest 1.0.x release, rather than 1.0.1 . RPATH support is nice for corner cases, but it should not be the default, ever. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Wouter Verhelst > Sent: Monday, May 29, 2017 10:40 > > 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. Agreed, though in the particular case where library A depends on library B, and the two are normally kept together in the same directory (whatever that directory might be), library A could have an RPATH entry of $ORIGIN to help the loader find B in the same directory. In general, though, RPATHs are bad for software that's going to be distributed to other systems, since they bind an installation directory into the binary. As Wouter says, that violates the principle of least surprise. In the products I work on, we avoid this issue with OpenSSL in particular by building OpenSSL as dynamically-linkable code (PIC, etc, as necesary for each platform), but put the objects into static (Windows) or archive (*ix) libraries. Then we link those libraries into dynamic objects of our own, with additional code on top of the OpenSSL APIs. That prevents accidental run-time binding to some other OpenSSL build that happens to be on the system. It requires hacking the OpenSSL build process, though, which doesn't natively accommodate this "build static libraries for subsequent dynamic linking" model. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)
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@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 |grep SONAME SONAME libssl.so.1.0.2 wouter@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
