Am 22.08.2017 um 12:15 schrieb Rahul Sabnis via curl-library:
> Hello,
>
> We are building curl with OpenSSL. We have also downloaded OpenSSL
> source and built it locally. While building curl we use whatever OpenSSL
> we have built.
>
> --with-ssl=<My OpenSSL Build Directory>
>
> The build is fine and we package and ship libcurl along with out product.
> But we cannot package and ship the openssl library with our product. The
> prerequisite is that OpenSSL will be already installed.
>
> When our product gets installed and libcurl is called, there is a crash.
> After investigation we identified that the version of OpenSSL installed
> on target machine is higher than that we have built libcurl with.
> For confirming this we replaced the openssl library with the one we
> built curl and everything worked fine.
>
> Questions:
> 1. Is this expected behavior or are we missing something here ?
> 2. Is it possible to make libcurl work with any OpenSSL library
> regardless of what it is built with ?
>
> Curl version: 7.54.0
> Platform: RHEL (But I expecting this problem on other platforms like
> AIX, Windows, HP-UX, Solaris).

I assume you have linked in OpenSSL dynamically (as a shared library)?

You can check the explicit dependency of your curl binary and of the
libcurl library with the command (Linux)

objdump -p /path/to/bin/curl
objdump -p /path/to/libcurl.so

where you need to replace "path/to with the correct path to your build
results. For Solaris it would be "elfdump -d", for HP-UX, AIX and
Windows I don't know.

I expect you will see something like:

...
   NEEDED libssl.so.1.0.0
   NEEDED libcrypto.so.1.0.0
...

That means during runtime, the linker will search for a shared lib with
an SONAME libssl.so.1.0.0 and libcrypto.so.1.0.0 respectively. Now
OpenSSL does have some compatibility properties. You can check for
instance a libssl from OpenSSL 1.1.0 and it will give:

objdump -p /path/to/libssl.so

...
   SONAME libssl.so.1.1
...

so that library has a different SONAME and the linker will *not* use it
during runtime.

More precisely any OpenSSL 1.0.SOMETHING provides the 1.0.0 API, and
1.1.0 provides an 1.1 API.

So the question would be:

- against which version of OpenSSL are you building curl/libcurl

- which version was loaded by the runtime linker on the target platform
   Your customer might find out using "ldd /path/to/libcurl.so" but she
would need to make sure, that the ldd command runs in a similar setup as
the real usage of the library, e.g. same LD_LIBRARY_PATH etc.

- what is the "NEEDED" output of "objdump -p" from your curl/libcurl?

- what is the stack of the crash?

Unfortunately although there is some API compatibility and version
check, what could happen, is that the binary loads different versions,
e.g. your libcurl load OpenSSL 1.1 and some system library, e.g. ldap,
load OpenSSL 1.0.2. That will probably result in bad situations.

Once you have different versions loaded, thinks become messy, because
the actual resolution of a symbol, e.g. a function name, might not be
done by version, but with the default search order of the runtime
linker. The default search order is not to search in a NEEDED lib of
your libcurl first, but instead it searches all libs in the order the
top-most binary has loaded them.

Easiest would be to compile curl against the platform standard OpenSSL.
If you need a newer one, than it can become tricky. Even when linking
statically, a version mismatch due to some other platform libs can
result, especially with ldap maybe loaded not by your libcurl, but by
some other dependecy living in the same binary as your libcurl.

Regards,

Rainer

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-08-22