pip check_hostname-flater efter in proxy: pip of de tunnel?

Twa ferskillende flaters printsje deselde pip-traceback, en de reparaasje dy't by de iene past makket de oare slimmer. In klient dy't te âld is om in tunnelde host te neamen, hat in upgrade nedich. In proxy dy't ferkear opnij ûndertekenet, hat in fertroud woartelsertifikaat nedich, net in downgrade. Fêststelle hokker fan de twa jo hawwe foardat jo in proxyfariabele bewurkje, want de paden liede yn tsjinoerstelde rjochtingen.

Lês de lêste frames foardat jo ynstellings oanrekke

Dêr't de traceback einiget, fertelt jo hokker laach it opjûn hat. As de slútframes binnen pip syn ynboude urllib3-TLS-koade sitte en de tekst klaget oer in hostnamme, koe de kliïntbibleteek in ferifikaasjestap net ôfmeitsje, en dat is folle faker in ferzjeprobleem as in sertifikaatprobleem. As de tekst ynstee in wegere ferbining, in net-oploste proxynamme of in HTTP 407 meldt, is it tunneleinstpunt skuldich en gjin upgrade sil dat feroarje.

Fêstlizze de pip-ferzje en de proxyfariabelen yn deselde shell dy't mislearret. In shell dy't iepene waard foardat de tunnel omheech kaam, draacht oare wearden as ien dy't dêrnei iepene waard, en it ferskil tusken har is faak de hiele diagnoaze.

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

Wannear't de klient âlder is as de tunnel

Aldere pip-releases brochten in HTTPS-stapel mei dy't de bestimmingshostnamme ferlear doe't de socket troch in tunnel omwoele wie. De check_hostname-boadskip is wat dy stapel útstjoert as er ferifikaasje berikt sûnder in namme om mei te fergelykjen. In upgrade hellet de flater fuort, om't de nijere klient de namme troch de handshake hâldt, en de feroaring is goedkeap genôch om earst te probearjen wannear't de slútframes nei ynboude TLS-koade wize.

As de yndeks net fan 'e mislearrende masine berikber is, helje dan in aktuele wheel op in host dy't dat kin en ynstallearje út it bestân. Brûk de bestânsnamme dy't jo eins downloade hawwe, net in ferzje dy't út in blogpost kopyeare is.

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

Wannear't de proxy ferkear opnij ûndertekenet

In proxy dy't TLS beëiniget en sertifikaten ûnder in bedriuwswoartel opnij útjaan, produsearret in oare flater: certificate verify failed, net in klacht oer in hostnamme. Dat ferskil is de oanwizing, want de klient berikte in tsjinner en fersmiet doe de identiteit dy't him sjen litten waard. De reparaasje is dy woartel eksplisyt te fertrouwen, itsij foar ien opdracht itsij fia de fariabele PIP_CERT, sadat de klient in keatling bouwe kin nei wat de proxy presintearret. It tafoegjen fan 'e woartel oan 'e fertrouwensopslach fan it systeem wurket ek, mar it feroaret fertrouwen foar elk programma op 'e masine, en dat is in grutter beslút as it reparearjen fan ien pakketynstallaasje.

Hâld --trusted-host as diagnoaze, nea as in rêsttastân. It skeakelet de kontrôle út dy't jo besochten te hâlden, sadat in echt ferkeard sertifikaat dernei sûn útsjocht. As jo it brûkten om ien pakket te ynstallearjen, helje it dan fuort en meitsje de keatling klear foar de folgjende release.

Jo eigen Python-koade negearret pip syn konfiguraasje folslein. In requests-oprop hat de proxy en it bondel nedich op it plak dêr't dy sesje se sjen kin, dêrom set it blok hjirûnder beide op it sesje-objekt.

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)

Wannear't it einpunt of de poarte ferkeard is

In tunnelklient skriuwt faak it systeemproxy oer wylst er ferbynt, wat pip rjochtsje kin op in host dy't nea op dy poarte antwurdet. Test it einpunt mei in klient dy't gjin pip is foardat jo in pip-ynstelling feroarje. As curl mislearret mei itselde proxy-argument, sit de flater boppe pip en gjin hoemannichte konfiguraasje binnen pip sil helpe.

De opdrachtflagge en de omjouwingsfariabelen sizze itselde foar ferskillende omfangen: de flagge jildt foar ien oanrop, de fariabelen foar elk proses dat dêrnei starten wurdt. Foegje NO_PROXY ta foar in ynterne yndeks sadat privee pakketferkear de omwei troch de tunnel oerslacht.

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

Bewarje de ynstelling en bewize dat it paad wurket

Bewarje de proxy yn pip syn eigen konfiguraasje as it de hjoeddeiske shell oerlibje moat, lês dan werom wat pip echt brûke sil. De debug-útfier neamt it bestân en de fariabele efter elke wearde, wat diskusjes oer foarrang flugger besljocht as it lêzen fan 'e dokumintaasje.

Ferifikaasje brûkt bewust twa kliïnten. It fersyk fan 'e standertbibleteek bewiist de rûte en de fertrouwenskeatling, wylst de download bewiist dat pip syn eigen konfiguraasje it dermei iens is. Wannear't de earste slagget en de twadde mislearret, sit it ferskil binnen pip en net yn it netwurk.

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