Ich gehe davon aus, dass ich (nach einigem Googeln) richtig davon ausgehe, dass Python nicht die installierte Version von OpenSSL verwendet, sondern stattdessen sein eigenes SSL-Modul nutzt und zum Upgrade neu erstellt werden muss.
Dies ist ein kleines, nicht grafisches Image auf einem Raspberry Pi, das auf Raspbian Jessie basiert. Ich plane später, wenn es die Zeit erlaubt, einen vollständigen Neuaufbau auf Basis einer aktuellen Distribution. Im Moment möchte ich die wichtigen Pakete nur manuell aktualisieren.
Ich habe die OpenSSL-Quelle von Git geklont, den stabilen Zweig 1.1.1 ausgecheckt und erstellt; nur die Standardeinstellungen configure, make, make testund sudo make install.
Jetzt versuche ich, Python neu zu erstellen, um diese Version zu verwenden.
Ich habe es mit Python 3 zum Laufen gebracht, aber es funktioniert nicht mit Python 2. Beides sind Tarballs, die heute von www.python.org/downloads/source/ heruntergeladen wurden und mit ./configureund makeohne zusätzliche Optionen erstellt wurden.
Ergebnis für 3.7.3: make ist erfolgreich, ebenso dieser Test
$ ./python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 1.1.1d-dev xx XXX xxxx
Die alte (installierte) Version von Python meldet OpenSSL 1.0.1t für Python und Python3, daher verwendet der neue Build die neue Version.
Ergebnis für 2.7.16: make ist nur teilweise erfolgreich, endet aber mit
Failed to build these modules:
_hashlib _ssl
und der gleiche Test geht
$ ./python -c "import ssl; print(ssl.OPENSSL_VERSION)"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/src/python/Python-2.7.16/Lib/ssl.py", line 98, in <module>
import _ssl # if we can't import it, let the error propagate
ImportError: No module named _ssl
Geben Sie beim Erstellen dieser Module Folgendes aus:
building '_ssl' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/arm-linux-gnueabihf -I/usr/local/include -I/usr/local/src/python/Python-2.7.16/Include -I/usr/local/src/python/Python-2.7.16 -c /usr/local/src/python/Python-2.7.16/Modules/_ssl.c -o build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_ssl.o
gcc -pthread -shared build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_ssl.o -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-armv7l-2.7/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-armv7l-2.7/_ssl.so: undefined symbol: OPENSSL_sk_num
building '_hashlib' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/arm-linux-gnueabihf -I/usr/local/include -I/usr/local/src/python/Python-2.7.16/Include -I/usr/local/src/python/Python-2.7.16 -c /usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.c -o build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-armv7l-2.7/usr/local/src/python/Python-2.7.16/Modules/_hashopenssl.o -L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-armv7l-2.7/_hashlib.so
*** WARNING: renaming "_hashlib" since importing it failed: build/lib.linux-armv7l-2.7/_hashlib.so: undefined symbol: OPENSSL_init_crypto
Antwort1
Wie in meinem Kommentar zur Frage ist die Antwort „Ja“.
[Bearbeiten: Zuerst dachte ich, es läge an meinen CFLAGS, aber das stimmte nicht.]
Endlich habe ich es geschafft. Der Build-Befehl für das _ssl-Modul enthält diese Schalter:
-L/usr/lib/arm-linux-gnueabihf -L/usr/local/lib
Der erste dieser beiden Speicherorte enthielt noch eine ALTE (1.0.0) Version von libssl.so. Die richtige Version befand sich unter dem zweiten Pfad.
Das Lustige ist, dass dies beim Erstellen von 3.7.3 keinen Unterschied gemacht zu haben scheint, nur für 2.7.16.