Памылка pip check_hostname за проксі: pip ці тунель?

Дзве розныя няспраўнасці друкуюць адзін і той жа трасіровачны вывад pip, і рамонт, які падыходзіць адной, робіць другую горш. Кліент, занадта стары, каб назваць тунеляваны хост, патрабуе абнаўлення. Проксі, які паўторна падпісвае трафік, патрабуе даверанага каранёвага сертыфіката, а не паніжэння версіі. Вызначце, якая з дзвюх у вас, перш чым змяняць зменную проксі, бо шляхі вядуць у процілеглых кірунках.

Прачытайце апошнія кадры, перш чым чапаць налады

Месца, дзе заканчваецца трасіроўка, кажа, які ўзровень здаўся. Калі закрывальныя кадры знаходзяцца ў TLS-кодзе urllib3, убудаваным у pip, і тэкст скардзіцца на імя хоста, кліенцкая бібліятэка не змагла завяршыць крок праверкі, і гэта праблема версіі значна часцей, чым праблема сертыфіката. Калі тэкст замест гэтага паведамляе пра адхіленае злучэнне, нявырашанае імя проксі або памылку HTTP 407, вінаваты канцавы пункт тунеля, і ніякае абнаўленне гэтага не зменіць.

Захавайце версію pip і зменныя проксі ў той жа абалонцы, якая падае. Абалонка, адкрытая да ўзняцця тунеля, мае іншыя значэнні, чым адкрытая пасля, і розніца паміж імі часта і ёсць увесь дыягназ.

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

Калі кліент старэйшы за тунель

Старыя выпускі pip уключалі HTTPS-стэк, які губляў імя прызначэння пасля таго, як сокет абгортваўся тунелем. Паведамленне check_hostname — гэта тое, што гэты стэк выдае, калі дасягае праверкі без імя для параўнання. Абнаўленне прыбірае няспраўнасць, бо новы кліент захоўвае імя падчас рукапаціскання, і змена дастаткова танна, каб паспрабаваць яе першай, калі закрывальныя кадры паказваюць на ўбудаваны TLS-код.

Калі індэкс недаступны з машыны, якая падае, атрымайце актуальны wheel на хосце, які можа, і ўсталюйце з файла. Выкарыстоўвайце імя файла, якое вы сапраўды спампавалі, а не версію, скапіраваную з посту ў блогу.

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

Калі проксі паўторна падпісвае трафік

Проксі, які завяршае TLS і паўторна выдае сертыфікаты пад карпаратыўным коранем, дае іншую памылку: certificate verify failed, а не скаргу на імя хоста. Гэтая розніца — ключ, бо кліент дасягнуў сервера і потым адхіліў паказаную яму ідэнтычнасць. Рамонт — даверыцца гэтаму корню яўна, ці для адной каманды, ці праз зменную PIP_CERT, каб кліент мог пабудаваць ланцуг да таго, што прадстаўляе проксі. Даданне корня ў сістэмнае сховішча даверу таксама працуе, але яно змяняе давер для кожнай праграмы на машыне, і гэта большае рашэнне, чым рамант аднаго ўсталявання пакета.

Трымайце --trusted-host як дыягнастычны сродак, ніколі як сталы стан. Ён выключае праверку, якую вы спрабавалі захаваць, таму сапраўдны няправільны сертыфікат пасля выглядае здаровым. Калі вы скарысталі яго, каб усталяваць адзін пакет, выдаліце яго і адрамантуйце ланцуг да наступнага выпуску.

Ваш уласны код Python цалкам ігнаруе канфігурацыю pip. Выкліку requests трэба перадаць проксі і зборнік туды, дзе гэтая сесія іх бачыць, і таму блок ніжэй усталёўвае абодва на аб'екце сесіі.

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)

Калі канцавы пункт або порт няправільныя

Кліент тунеля часта перапісвае сістэмны проксі падчас падключэння, і гэта можа пакінуць pip накіраваным на хост, які ніколі не адказвае на гэтым порце. Праверце канцавы пункт кліентам, які не з'яўляецца pip, перш чым змяняць любыя налады pip. Калі curl падае з тым жа аргументам проксі, няспраўнасць знаходзіцца вышэй за pip, і ніякая колькасць налад унутры pip не дапаможа.

Сцяг каманды і зменныя асяроддзя кажуць адно і тое ж для розных абсягаў: сцяг дзейнічае для аднаго выкліку, зменныя — для кожнага працэсу, запушчанага пасля. Дадайце NO_PROXY для ўнутранага індэкса, каб прыватны трафік пакетаў абышоў аб'езд праз тунель.

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

Захавайце наладу і дакажыце, што шлях працуе

Захоўвайце проксі ў ўласнай канфігурацыі pip, калі яно павінна перажыць бягучую абалонку, затым прачытайце, што pip сапраўды будзе выкарыстоўваць. Вывад debug называе файл і зменную за кожным значэннем, і гэта вырашае спрэчкі пра прыярытэт хутчэй, чым чытанне дакументацыі.

Праверка наўмысна выкарыстоўвае двух кліентаў. Запыт са стандартнай бібліятэкі даказвае маршрут і ланцуг даверу, а спампоўка даказвае, што ўласная канфігурацыя pip з імі згодная. Калі першы паспяховы, а другі падае, розніца ўнутры pip, а не ў сетцы.

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