Во-первых...

Ничего из этого делать не нужно

Ошибка, на которую вы ссылаетесь, была исправлена ​​в Curl версии 7.51.0 .

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

Вы указали Debian Stretch, который в настоящее время использует 7.52.1 . Неважно, что на нем установлена ​​более старая версия OpenSSL --, у вас все еще есть обновленный Curl.

Таким образом, до тех пор, пока эта система поддерживается -до -даты (через apt), в ней уже есть исправление.

Динамический или статический

Теперь о вашем первоначальном вопросе:

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

Нет. Если вы не установили какие-то определенные переменные при запуске ./configure, результирующий исполняемый файл динамически компонуется и требует отдельного libcurl.so. Один из них будет построен одновременно.

И если вы не скопировали этот библиотечный файл на второй сервер и не поместили его в путь, по которому его найдет загрузчик , вы будете использовать тот, который уже установлен (в /usr/lib/x86_64-linux-gnu/). ]. Если вы запустите readelf -dдля этого файла , вы увидите, с какой версией OpenSSL он связан.

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

Если бы вы попытались использовать более новую версию libcurl.so.4на втором сервере, вы бы увидели примерно такую ​​ошибку:

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

Подводя итог :Ваша копия Curl использует,и правильно сообщает версию установленного OpenSSL. Утечка памяти затронет вас только в том случае, если вы вручную собрали версию Curl до исправления (, т.е. старше 7.51.0 ).