pip check_hostname'i viga puhverserveri taga: pip või tunnel?

Kaks erinevat tõrget trükivad sama pipi jälje ja ühele sobiv parandus teeb teise hullemaks. Klient, mis on liiga vana, et tunneliga kaetud hosti nimetada, vajab uuendust. Puhverserver, mis liiklust ümber signeerib, vajab usaldatud juursertifikaati, mitte versiooni langetamist. Tehke kindlaks, kumb neist kahest teil on, enne kui muudate puhverserveri muutujat, sest teed viivad vastassuundades.

Lugege viimaseid kaadreid enne seadete puudutamist

Jälje lõpp näitab, milline kiht alla andis. Kui lõpukaadrid asuvad pipi sees olevas urllib3 TLS-koodis ja tekst kurdab hostinime üle, ei suutnud kliendi teek kontrollsammu lõpetada, ja see on versiooniprobleem palju sagedamini kui sertifikaadiprobleem. Kui tekst teatab hoopis tagasi lükatud ühendusest, lahendamata puhverserveri nimest või HTTP 407 veast, on süüdi tunneli lõpp-punkt ja ükski uuendus ei muuda seda.

Jäädvustage pipi versioon ja puhverserveri muutujad samas kestas, mis ebaõnnestub. Enne tunneli tõusmist avatud kest kannab teistsuguseid väärtusi kui pärast avatu, ja nende vahe on sageli kogu diagnoos.

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

Kui klient on tunnelist vanem

Vanemad pipi väljaanded sisaldasid HTTPS-pinu, mis kaotas sihtkoha hostinime, kui socket oli tunneliga mähitud. check_hostname'i teade on see, mida too pinu väljastab, kui jõuab kontrollini ilma võrdlemiseks vajaliku nimeta. Uuendus kõrvaldab vea, sest uuem klient hoiab nime kätlemise ajal alles, ja muudatus on piisavalt odav, et proovida seda kõigepealt alati, kui lõpukaadrid osutavad kaasatud TLS-koodile.

Kui indeksit ei saa ebaõnnestuvalt masinalt kätte, laadige värske wheel alla hostil, mis saab, ja paigaldage failist. Kasutage failinime, mille te tegelikult alla laadisite, mitte blogipostitusest kopeeritud versiooni.

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

Kui puhverserver liiklust ümber signeerib

Puhverserver, mis lõpetab TLS-i ja annab sertifikaate uuesti välja ettevõtte juure all, tekitab teistsuguse vea: certificate verify failed, mitte hostinime kaebus. See erinevus on vihje, sest klient jõudis serverini ja lükkas siis tagasi talle näidatud identiteedi. Parandus on usaldada seda juurt selgesõnaliselt, kas ühe käsu jaoks või muutuja PIP_CERT kaudu, et klient saaks ehitada ahela selleni, mida puhverserver esitab. Juure lisamine süsteemi usaldushoidlasse töötab samuti, kuid muudab usaldust iga programmi jaoks masinas, ja see on suurem otsus kui ühe paketi paigalduse parandamine.

Hoidke --trusted-host diagnostikavahendina, mitte kunagi püsiva olekuna. See lülitab välja kontrolli, mida te püüdsite hoida, nii et tõeliselt vale sertifikaat näeb pärast terve välja. Kui kasutasite seda ühe paketi paigaldamiseks, eemaldage see ja parandage ahel enne järgmist väljaannet.

Teie enda Pythoni kood eirab pipi konfiguratsiooni täielikult. requests-kutse vajab puhverserverit ja komplekti sinna, kus see sessioon neid näeb, seepärast seab allolev plokk mõlemad sessiooniobjektile.

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)

Kui lõpp-punkt või port on vale

Tunneliklient kirjutab ühendudes sageli süsteemi puhverserveri ümber, mis võib jätta pipi osutama hostile, mis sellel pordil kunagi ei vasta. Testige lõpp-punkti kliendiga, mis ei ole pip, enne kui muudate ükskõik millist pipi seadet. Kui curl ebaõnnestub sama puhverserveri argumendiga, asub viga pipist kõrgemal ja ükski konfiguratsioon pipi sees ei aita.

Käsulipp ja keskkonnamuutujad ütlevad sama asja erinevatele ulatustele: lipp kehtib ühe kutse kohta, muutujad iga hiljem käivitatud protsessi kohta. Lisage NO_PROXY sisemise indeksi jaoks, et privaatne paketiliiklus jätaks tunneliläbi sõidu vahele.

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

Püsitage seade ja tõestage, et tee töötab

Hoidke puhverserver pipi enda konfiguratsioonis, kui see peab praegusest kestast üle elama, ja lugege siis, mida pip tegelikult kasutab. Debugi väljund nimetab iga väärtuse taga oleva faili ja muutuja, mis lahendab vaidlused tähtsuse üle kiiremini kui dokumentatsiooni lugemine.

Kontroll kasutab meelega kahte klienti. Standardteegi päring tõestab marsruudi ja usaldusahela, allalaadimine aga tõestab, et pipi enda konfiguratsioon on nendega nõus. Kui esimene õnnestub ja teine ebaõnnestub, on erinevus pipi sees, mitte võrgus.

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