O mesmo binário curl mostra uma versão diferente do openssl em 2 servidores diferentes

Question

então eu construí o curl (possivelmente incorretamente) no debian 9 x64, e depois do comando curl -V eu posso ver que ele usa a nova versão:

OpenSSL/1.1.0f

Depois disso, eu copiei a mesma biblioteca para outra instância do debian 9, e depois de executar o curl -V, vejo que ela usa a versão antiga:

OpenSSL/1.0.2l

-Qual é a causa disso?

-Isso significa que, de alguma forma, construí o curl incorretamente e que a versão atual do openssl não é a que ele mostra?

-Não é o openssl estaticamente construído e, portanto, permanece dentro de binário curl?

    

Answer 1

Em primeiro lugar ...

Você não precisa fazer nada disso

O erro ao qual você se vinculou foi corrigido no Curl versão 7.51.0 .

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

Você especificou o Debian Stretch, que atualmente usa o 7.52.1 . Não importa que tenha uma versão mais antiga do OpenSSL instalada - você ainda tem o Curl atualizado.

Portanto, enquanto esse sistema for mantido atualizado (via apt ), ele já terá a correção.

Dinâmico ou estático

Agora, na sua pergunta original:

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

Não. A menos que você defina algumas variáveis específicas quando você executou ./configure , o executável resultante será vinculado dinamicamente e precisará de um libcurl.so separado. Um deles terá sido construído ao mesmo tempo.

E, a menos que você tenha copiado esse arquivo de biblioteca para o segundo servidor e colocado em um caminho onde o carregador o encontre , você usará o que já está instalado (em /usr/lib/x86_64-linux-gnu/ ). Se você executar readelf -d no arquivo que , verá qual versão do OpenSSL está vinculada.

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

Se você tiver tentado usar sua versão mais recente de libcurl.so.4 no segundo servidor, você teria visto um erro como este:

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

Para resumir: Sua cópia do Curl está usando e relatando corretamente a versão do OpenSSL que está instalada. A única maneira de você ser afetado pelo vazamento de memória é se você tivesse construído manualmente uma versão do Curl antes da correção (ou seja, mais antiga que 7.51.0).