0

so I have built curl (possibly incorrectly) on debian 9 x64, and after curl -V command I can see that it uses the new version:

OpenSSL/1.1.0f

After that, I copied the very same library into another debian 9 instance, and after running curl -V I see that it uses the old version:

OpenSSL/1.0.2l

-What is the cause of this?

-Does it mean I have somehow built curl incorrectly and that the actual openssl version is not the one that it shows?

-Isn't the openssl statically built, and therefore remains inside curl binary?

  • What is the output of ldd $(./curl) on each server? – JigglyNaga Sep 20 '18 at 11:44
  • @JigglyNaga Hi, both outputs gives same paths: libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 – Boy Sep 20 '18 at 11:50
  • What exact steps did you take to "build curl"? When you say you "copied the very same library", what exact file(s) did you copy, to what path(s)? I expect your copy of curl is dynamically linked, and the reported ssl version is the one installed on each server. – JigglyNaga Sep 20 '18 at 11:55
  • 1
    Did you verify you're actually using the copied curl with which curl or running it from the current directory with ./curl? – Mikael Kjær Sep 20 '18 at 12:01
  • I installed the libssl-dev, but I had problem with curl choosing the old version of openssl because they were in the same dir, and the old v. comes with the distribution image and that old version seems to be required for openssh (if i want to use the one from the package repo). I temporary removed that old version and built the curl, and then undo the deletion. I think I made huge mistake by doing it... did I? I thought I'm gonna build curl statically. – Boy Sep 20 '18 at 12:03
1

Firstly...

You don't need to do any of this

The bug you link to was fixed in Curl version 7.51.0.

  • openssl: fix per-thread memory leak using 1.0.1 or 1.0.2

You specified Debian Stretch, which currently uses 7.52.1. It doesn't matter that it has an older version of OpenSSL installed -- you still have the updated Curl.

So as long as that system has been kept up-to-date (via apt) it already has the fix.

Dynamic or static

Now, onto your original question:

Isn't the openssl statically built, and therefore remains inside curl binary?

No. Unless you set some specific variables when you ran ./configure, the resulting executable is dynamically linked, and needs a separate libcurl.so. One of those will have been built at the same time.

And unless you copied that library file to the second server and placed it in a path where the loader would find it, then you will be using the one that is already installed (under /usr/lib/x86_64-linux-gnu/). If you run readelf -d on that file, you will see which version of OpenSSL it is linked against.

 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.2]

If you had tried to use your newer version of libcurl.so.4 on the second server, you would have seen an error something like this:

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

To sum up: Your copy of Curl is using, and correctly reporting, the version of OpenSSL that is installed. The only way you would be affected by the memory leak is if you had manually built a version of Curl from before the fix (ie. older than 7.51.0).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.