Ich habe ein altes System, das auf einer Mandriva 2010.1-Distribution basiert und keine Updates mehr erhält.
Bis vor kurzem konnte ich die integrierten Git-Binärdateien verwenden, um mit GitHub zu kommunizieren, aber da sie ihre Richtlinien bezüglich unsicherer Protokolle geändert haben, erhalte ich jetzt diese Fehlermeldung:
fatal: unable to access 'https://github.com/user/repo.git/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Es gibt viele Antworten, die sich auf diese Nachricht beziehen. Die meisten davon sind einfach "Update your client", was für mich in Ordnung wäre, wenn ich auf absehbare Zeit nicht an diesem uralten System hängen würde.
Glücklicherweise habe ich alle erforderlichen Build-Tools auf dieser Maschine, und deshalb habe ich die Quellen für git heruntergeladen 2.16.2, entpackt /usr/src/git-2.16.2und diese Befehle naiv ausgeführt:
./configure make ./git --exec-path=/usr/src/git-2.16.2 clone https://github.com/user/repo.git
Aber wie Sie wissen, konnte das Problem dadurch nicht gelöst werden.
Ich schaute also weiter darauf hin, wie git-remote-httpsgebaut wird und stellte fest, dass ich auch eine neuere libcurlund eine neuere open-sslBibliothek brauche .
Also habe ich mit OpenSSL angefangen /usr/src/openssl-1.1.0gund es mit folgenden Befehlen eingebaut:
./config enable-shared enable-egd make
Dies ist gut gelungen, also habe ich weitergegangen, um zu curlversuchen, sicherzustellen, dass es das verwendet, das opensslich gerade gebaut habe. Ich installierte seine Quellen im Inneren /usr/src/curl-7.58.0und nach einigem Ausprobieren und Betrachten verschiedener Ressourcen kam ich mit den folgenden Befehlen:
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
Das baut gut und ich kann libcurl.so.4innen finden/usr/src/curl-7.58.0/lib/.libs
Ich bin also zum letzten Schritt übergegangen, der Git aus Quellen /usr/src/git-2.16.2mit folgenden Befehlen aufbaut:
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
Mit all dem, erhalte ich eine Reihe von git Binärdateien und wenn die Verwendung readelfauf git-remote-https, erscheint es richtig:
Wenn ich jedoch denselben Befehl oben zum Abrufen desselben Repositorys starte, erhalte ich eine ganz andere Ausgabe:
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]
Ich habe also offensichtlich etwas falsch in der Art und Weise, wie ich meine Git-Binaries erstellt habe, aber ich kann nicht wirklich herausfinden, was.
Beim Erstellen des makeGit- Protokolls habe ich die folgende Warnmeldung festgestellt:
/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
Es wird für einige git-remoteausführbare Dateien wiederholt und ich finde es ein bisschen seltsam. Ich meine, readelfsagt mir, es libcurl.so.4ist die, die verwendet wird, und trotzdem scheint es, als ob der Linker immer noch eine alte Version aus meinen veralteten Systembibliotheken importiert.
Das mag die Segfaults erklären, die ich beobachte, aber wie hätte ich diese ganze Kette bauen sollen?
Jede Hilfe wäre sehr dankbar.
1 Antwort auf die Frage
1
OBones
Um den Ursprung des Absturzes zu erforschen, habe ich ldd -aauf git-remote-httpsund es zeigte sich, dass es wurde mit libcurl.so.4von Systemordnern, nicht aus meinem libcurlOrdner. Als Ergebnis erlaubte der Loader, dass zwei Versionen libcryptoverwendet wurden, was ziemlich sicher zu dem Segfault führte, das ich beobachtete.
Nachdem sichergestellt make cleanwurde, dass in jedem Verzeichnis sichergestellt wurde, befindet sich ich jetzt in einer Arbeitssituation mit den folgenden Befehlen:
Für OpenSSL
./config enable-shared enable-egd make
Dann für 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
Stellen Sie an diesem Punkt sicher, dass libcurl.so.4in vorhanden ist /usr/src/curl-7.58.0/lib/.libs. Es scheint, --enable-libcurl-optiondass dies sicherstellt, dass dies der Fall ist, während die oben verwendete Befehlszeile nicht immer ausreicht.
Dann endlich für git selbst:
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
Nun werden lddSie sehen, dass /usr/src/curl-7.58.0/lib/.libs/libcurl.so.4verwendet wird und nicht die aus den Systemverzeichnissen. Das bedeutet, dass der folgende git-Befehl ordnungsgemäß funktioniert: