Criando o git em uma antiga distribuição Linux

1

Eu tenho um sistema antigo baseado em uma distribuição do Mandriva 2010.1 que não recebe mais atualizações.

Até muito recentemente, eu era capaz de usar os binários git internos para se comunicar com o GitHub muito bem, mas como eles mudaram sua política em relação aos protocolos inseguros, agora estou recebendo esta mensagem de erro:

fatal: unable to access 'https://github.com/user/repo.git/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

Há muitas respostas relacionadas a essa mensagem, a maioria delas simplesmente "atualiza seu cliente", o que seria ótimo para mim se eu não estivesse preso a esse antigo sistema no futuro previsível.

Felizmente para mim, eu tenho todas as ferramentas de compilação necessárias nessa máquina e, por isso, baixei as fontes do git 2.16.2 , as extraí em /usr/src/git-2.16.2 e ingenuamente executei esses comandos:

./configure
make
./git --exec-path=/usr/src/git-2.16.2 clone https://github.com/user/repo.git

Mas, como seria óbvio para você, isso não resolveu o problema.

Analisei ainda como git-remote-https é criado e descobri que também precisaria de uma biblioteca libcurl mais recente e uma biblioteca open-ssl mais recente.

Então comecei com o OpenSSL e coloquei em /usr/src/openssl-1.1.0g e criei com estes comandos:

./config enable-shared enable-egd
make

Isso foi muito bem, então mudei para construir curl tentando garantir que usaria o openssl que acabei de criar. Eu instalei suas fontes dentro de /usr/src/curl-7.58.0 e depois de um pouco de tentativa e erro, olhando para vários recursos, eu criei os seguintes comandos:

LDFLAGS="-L/usr/src/openssl-1.1.0g -Wl,-rpath,/usr/src/openssl-1.1.0g" LIBS="-ldl" ./configure --with-ssl=/usr/src/openssl-1.1.0g --with-libssl-prefix=/usr/src/openssl-1.1.0g --disable-ldap
make

Isso cria muito bem e eu posso encontrar libcurl.so.4 dentro de /usr/src/curl-7.58.0/lib/.libs

Por isso, mudei para a última etapa, que está criando o git de fontes localizadas dentro de /usr/src/git-2.16.2 com os seguintes comandos:

LDFLAGS="-L/usr/src/openssl-1.1.0g -L/usr/src/curl-7.58.0 -Wl,-rpath,/usr/src/openssl-1.1.0g,-rpath,/usr/src/curl-7.58.0/lib/.libs" LIBS="-ldl" ./configure --with-curl=/usr/src/curl-7.58.0 --with-openssl=/usr/src/openssl-1.1.0g
make

Com tudo isso, recebo um conjunto de binários git e, se usar readelf on git-remote-https , parece correto:

Dynamic section at offset 0x125448 contains 27 entries:

  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libexpat.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [/usr/src/openssl-1.1.0g:/usr/src/curl-7.58.0/lib/.libs:/usr/src/curl-7.58.0/lib]
 0x000000000000000c (INIT)               0x403870
 0x000000000000000d (FINI)               0x4e7448
 0x000000006ffffef5 (GNU_HASH)           0x400240
 0x0000000000000005 (STRTAB)             0x401838
 0x0000000000000006 (SYMTAB)             0x4002a8
 0x000000000000000a (STRSZ)              2411 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x725658
 0x0000000000000002 (PLTRELSZ)           5160 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x402448
 0x0000000000000007 (RELA)               0x4023d0
 0x0000000000000008 (RELASZ)             120 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x402370
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x4021a4
 0x0000000000000000 (NULL)               0x0

No entanto, se eu iniciar o mesmo comando acima para recuperar o mesmo repositório, recebo uma saída muito diferente:

Cloning into 'repo'...
warning: templates not found /usr/local/share/git-core/templates
kernel: git-remote-http[14950]: segfault at 0 ip 00007f027380ce66 sp 00007fffa34bf5f8 error 4 in libc-2.11.1.so[7f0273793000+163000]

Então, claramente, há algo errado na maneira como eu construí meus binários git, mas eu não consigo descobrir o que.

Inspecionando o log de make ao construir o Git, notei a seguinte mensagem de aviso:

/usr/bin/ld: warning: libssl.so.1.0.0, needed by /usr/lib/gcc/x86_64-manbo-linux-gnu/4.4.3/../../../../lib64/libcurl.so, may conflict with libssl.so.1.1

Ele se repete para um número de git-remote executáveis e acho um pouco estranho. Quero dizer, readelf me diz que libcurl.so.4 é o que é usado e, ainda assim, parece que o vinculador ainda está importando uma versão antiga de minhas bibliotecas desatualizadas do sistema.

Isso pode muito bem explicar os segfaults que estou observando, mas então, como eu deveria ter construído toda essa cadeia?

Qualquer ajuda seria muito apreciada.

    
por OBones 26.03.2018 / 17:45

1 resposta

1

Para explorar ainda mais a origem da falha, usei ldd -a on git-remote-https e ele mostrou que estava usando libcurl.so.4 das pastas do sistema, não da minha pasta libcurl . Como resultado, o carregador estava permitindo que duas versões de libcrypto fossem usadas, levando muito seguramente ao segfault que eu estava observando.

No entanto, depois de ter certeza de que make clean foi chamado em cada diretório, agora estou em uma situação de trabalho, com o seguinte conjunto de comandos:

Para o OpenSSL

./config enable-shared enable-egd
make

Então para CURL

LDFLAGS="-L/usr/src/openssl-1.1.0g -Wl,-rpath,/usr/src/openssl-1.1.0g" LIBS="-ldl" ./configure --with-ssl=/usr/src/openssl-1.1.0g --with-libssl-prefix=/usr/src/openssl-1.1.0g --disable-ldap --enable-libcurl-option
make

Nesse ponto, certifique-se de que libcurl.so.4 esteja presente em /usr/src/curl-7.58.0/lib/.libs . Parece que o --enable-libcurl-option garante que esse seja o caso, enquanto a linha de comando usada acima nem sempre funciona.

Então, finalmente, para o próprio git:

LDFLAGS="-L/usr/src/openssl-1.1.0g -L/usr/src/curl-7.58.0 -Wl,-rpath,/usr/src/openssl-1.1.0g,-rpath,/usr/src/curl-7.58.0/lib/.libs" LIBS="-ldl" ./configure --with-curl=/usr/src/curl-7.58.0 --with-openssl=/usr/src/openssl-1.1.0g
make

Agora, usando ldd , você verá que /usr/src/curl-7.58.0/lib/.libs/libcurl.so.4 é usado e não o dos diretórios do sistema. Isso significa que o seguinte comando git funciona corretamente:

./git --exec-path=/usr/src/git-2.16.2 clone https://github.com/user/repo.git

é um pouco trabalhoso exigir o uso de --exec-path para cada comando git, mas o comando alias é bastante conveniente neste caso.

    
por 30.03.2018 / 17:44