pip check_hostname-Fehler hannert engem Proxy: pip oder den Tunnel?

Zwou verschidden Feeler drécken déi selwecht pip-Spur, an d’Reparatur déi fir déi eng passt, mécht déi aner schléchter. En Client deen ze al ass fir en tunneléierten Host ze nennen, brauch en Update. En Proxy deen den Trafik nei ënnerschreift, brauch en vertraute Wuerzelszertifikat, keen Downgrade. Fannt eraus wéi eng vun den zwou Dir hutt, ier Dir eng Proxy-Variabel ännert, well d’Weeër a géigendeels Richtunge ginn.

Liest déi lescht Frame ier Dir d’Astellunge beréiert

Wou d’Spur ophält, seet Iech wéi eng Schicht opginn huet. Wann déi lescht Frame am TLS-Code vum urllib3 sinn dee mat pip kënnt an den Text iwwer en Hostnumm klot, konnt d’Client-Bibliothéik en Iwwerpréifungsschrëtt net fäerdeg maachen, an dat ass vill méi dacks e Versiounsproblem wéi e Zertifikatsproblem. Wann den Text amplaz eng verworf Verbindung, en ongeléisten Proxy-Numm oder en HTTP 407 mëldt, ass de Schlusspunkt vum Tunnel schold a keen Update wäert dat änneren.

Halt d’pip-Versioun an d’Proxy-Variabelen an der selwechter Shell fest, déi feelt. Eng Shell déi opgemaach gouf ier den Tunnel eropkomm ass, dréit aner Wäerter wéi eng déi duerno opgemaach gouf, an den Ënnerscheed tëscht hinnen ass dacks déi ganz Diagnos.

python3 -m pip --version
env | grep -i -E 'proxy|no_proxy'

Wann de Client méi al ass wéi den Tunnel

Méi al pip-Versioune bruechten en HTTPS-Stack mat, deen den Zil-Hostnumm verluer huet soubal de Socket vun engem Tunnel ëmhëllt war. D’check_hostname-Meldung ass dat wat dee Stack ausgëtt wann en d’Iwwerpréifung ouni Numm zum Vergläiche erreecht. En Update hëlt de Feeler ewech, well de méi neie Client den Numm duerch den Handshake behält, an d’Ännerung ass bëlleg genuch fir se als éischt ze probéieren wann ëmmer déi lescht Frame op de matgeliewerten TLS-Code weisen.

Wann den Index vun der feelender Maschinn aus net erreechbar ass, luet eng aktuell Wheel op engem Host deen dat kann a installéiert se aus der Datei. Benotzt den Dateinumm deen Dir tatsächlech erofgelueden hutt, net eng Versioun déi aus engem Blogpost kopéiert gouf.

python3 -m pip install --upgrade pip
python3 -m pip install ./pip-24.2-py3-none-any.whl

Wann de Proxy den Trafik nei ënnerschreift

En Proxy deen TLS ofschléisst an Zertifikater ënner enger Firmenwuerzel nei ausstellt, produzéiert en anere Feeler: certificate verify failed, net eng Beschwéier iwwer en Hostnumm. Dee Ënnerscheed ass den Hiwäis, well de Client en Server erreecht huet an dann d’Identitéit verworf huet déi him gewise gouf. D’Reparatur ass dëser Wuerzel explizit ze vertrauen, entweder fir eng eenzeg Kommando oder iwwer d’Variabel PIP_CERT, sou datt de Client eng Kette bauen kann bis zu deem wat de Proxy presentéiert. D’Wuerzel an de Vertrauensspäicher vum System ze setzen funktionéiert och, awer et ännert d’Vertraue fir all Programm op der Maschinn, an dat ass eng méi grouss Entscheedung wéi eng eenzeg Package-Installatioun ze reparéieren.

Halt --trusted-host als Diagnos, ni als Dauerzoustand. Et schalt d’Iwwerpréifung aus déi Dir versicht hutt ze behalen, sou datt en wierklech falschen Zertifikat duerno gesond ausgesäit. Wann Dir et benotzt hutt fir ee Package z’installéieren, hëlt et ewech a reparéiert d’Kette virun der nächster Versioun.

Ären eegene Python-Code ignoréiert d’pip-Konfiguratioun komplett. En requests-Uruff brauch de Proxy an de Bundle do higinn wou déi Sessioun se gesäit, dofir setzt de Block hei drënner béides um Sessiounsobjekt.

pip install --cert /usr/local/share/ca-certificates/corp-root.crt requests
export PIP_CERT=/usr/local/share/ca-certificates/corp-root.crt

s = requests.Session()
s.proxies = {"https": "http://10.20.30.40:8080"}
s.verify = "/usr/local/share/ca-certificates/corp-root.crt"
s.get("https://pypi.org/simple/", timeout=15)

Wann de Schlusspunkt oder de Port falsch ass

En Tunnel-Client schreift dacks de System-Proxy ëm während en sech verbënnt, wat pip op en Host weise kann deen op deem Port ni äntwert. Test de Schlusspunkt mat engem Client deen net pip ass ier Dir eng pip-Astellung ännert. Wann curl mat dem selwechten Proxy-Argument feelt, sëtzt de Feeler iwwer pip a keng Konfiguratioun innerhalb vum pip wäert hëllefen.

D’Kommando-Flag an d’Ëmweltvariabelen soen datselwecht fir verschidden Ëmfang: d’Flag gëllt fir een Uruff, d’Variabelen fir all Prozess deen duerno gestart gëtt. Füügt NO_PROXY fir en internen Index derbäi, sou datt private Package-Trafik den Ëmwee duerch den Tunnel iwwerspréngt.

curl -x http://proxy.corp.internal:8080 --head https://pypi.org/simple/
pip install --proxy http://proxy.corp.internal:8080 requests

Späichert d’Astellung a beweist datt de Wee funktionéiert

Späichert de Proxy an der pip senger eegener Konfiguratioun wann en déi aktuell Shell iwwerliewe soll, liest dann zréck wat pip wierklech benotze wäert. D’Debug-Ausgab nennt d’Datei an d’Variabel hannert all Wäert, wat Diskussiounen iwwer Prioritéit méi séier klärt wéi d’Dokumentatioun ze liesen.

D’Iwwerpréifung benotzt bewosst zwee Clienten. D’Ufro aus der Standardbibliothéik beweist d’Route an d’Vertrauenskette, während den Download beweist datt dem pip seng eege Konfiguratioun mat hinnen d’accord ass. Wann déi éischt geléngt an déi zweet feelt, ass den Ënnerscheed am pip an net am Netz.

pip config set global.proxy http://proxy.corp.internal:8080
pip config debug
python3 -c "import urllib.request as r; print(r.urlopen('https://pypi.org/simple/').status)"
pip download --no-deps -d /tmp/wheelcheck requests