Ralat check_hostname pip di belakang proksi: pip atau terowong?

Dua kegagalan berbeza mencetak jejak pip yang sama, dan pembaikan yang sesuai untuk satu menjadikan yang lain lebih teruk. Klien yang terlalu lama untuk menamakan hos yang diterowongkan memerlukan peningkatan. Proksi yang menandatangani semula trafik memerlukan sijil akar yang dipercayai, bukan kemerosotan versi. Tentukan yang mana antara keduanya anda miliki sebelum menyunting pemboleh ubah proksi, kerana laluannya menuju arah yang bertentangan.

Baca bingkai terakhir sebelum menyentuh tetapan

Di mana jejak berakhir memberitahu anda lapisan mana yang mengalah. Jika bingkai penutup berada di dalam kod TLS urllib3 yang dibundel dengan pip dan teksnya mengeluh tentang nama hos, pustaka klien tidak dapat menyelesaikan langkah pengesahan, dan itu masalah versi jauh lebih kerap daripada masalah sijil. Jika teksnya sebaliknya melaporkan sambungan yang ditolak, nama proksi yang tidak diselesaikan atau HTTP 407, titik akhir terowong yang bersalah dan tiada peningkatan akan mengubahnya.

Tangkap versi pip dan pemboleh ubah proksi dalam shell yang sama yang gagal. Shell yang dibuka sebelum terowong naik membawa nilai berbeza daripada yang dibuka selepasnya, dan perbezaan antara keduanya selalunya keseluruhan diagnosis.

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

Apabila klien lebih tua daripada terowong

Keluaran pip yang lebih lama membawa tindanan HTTPS yang kehilangan nama hos destinasi apabila soket dibalut terowong. Mesej check_hostname ialah yang dikeluarkan oleh tindanan itu apabila ia mencapai pengesahan tanpa nama untuk dibandingkan. Peningkatan menghapuskan kerosakan kerana klien yang lebih baharu mengekalkan nama sepanjang jabat tangan, dan perubahannya cukup murah untuk dicuba dahulu setiap kali bingkai penutup menunjuk kepada kod TLS yang dibundel.

Jika indeks tidak dapat dicapai dari mesin yang gagal, dapatkan wheel semasa pada hos yang boleh dan pasang dari fail itu. Gunakan nama fail yang benar-benar anda muat turun, bukan versi yang disalin daripada catatan blog.

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

Apabila proksi menandatangani semula trafik

Proksi yang menamatkan TLS dan mengeluarkan semula sijil di bawah akar korporat menghasilkan ralat yang berbeza: certificate verify failed, bukan aduan nama hos. Perbezaan itulah petunjuknya, kerana klien sampai ke pelayan kemudian menolak identiti yang ditunjukkan kepadanya. Pembaikannya ialah mempercayai akar itu secara jelas, sama ada untuk satu arahan atau melalui pemboleh ubah PIP_CERT, supaya klien boleh membina rantaian kepada apa yang dipersembahkan oleh proksi. Menambah akar ke stor kepercayaan sistem juga berkesan, tetapi ia mengubah kepercayaan bagi setiap program pada mesin, dan itu keputusan yang lebih besar daripada membaiki satu pemasangan pakej.

Kekalkan --trusted-host sebagai diagnostik, jangan sekali-kali sebagai keadaan tetap. Ia mematikan pemeriksaan yang anda cuba kekalkan, jadi sijil yang benar-benar salah kelihatan sihat selepas itu. Jika anda menggunakannya untuk memasang satu pakej, buangnya dan baiki rantaian sebelum keluaran seterusnya.

Kod Python anda sendiri mengabaikan konfigurasi pip sepenuhnya. Panggilan requests memerlukan proksi dan bundel dihantar ke tempat sesi itu dapat melihatnya, itulah sebabnya blok di bawah menetapkan kedua-duanya pada objek sesi.

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)

Apabila titik akhir atau port salah

Klien terowong sering menulis semula proksi sistem semasa menyambung, yang boleh membiarkan pip menunjuk ke hos yang tidak pernah menjawab pada port itu. Uji titik akhir dengan klien yang bukan pip sebelum mengubah mana-mana tetapan pip. Jika curl gagal dengan argumen proksi yang sama, kerosakan terletak di atas pip dan tiada konfigurasi di dalam pip akan membantu.

Bendera arahan dan pemboleh ubah persekitaran mengatakan perkara yang sama kepada skop berbeza: bendera terpakai untuk satu panggilan, pemboleh ubah untuk setiap proses yang dimulakan selepasnya. Tambah NO_PROXY untuk indeks dalaman supaya trafik pakej peribadi melangkau lencongan melalui terowong.

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

Kekalkan tetapan dan buktikan laluan itu berfungsi

Simpan proksi dalam konfigurasi pip sendiri apabila ia perlu bertahan melebihi shell semasa, kemudian baca semula apa yang sebenarnya akan digunakan oleh pip. Output debug menamakan fail dan pemboleh ubah di sebalik setiap nilai, yang menyelesaikan perdebatan tentang keutamaan lebih pantas daripada membaca dokumentasi.

Pengesahan sengaja menggunakan dua klien. Permintaan daripada pustaka standard membuktikan laluan dan rantaian kepercayaan, manakala muat turun membuktikan bahawa konfigurasi pip sendiri bersetuju dengannya. Apabila yang pertama berjaya dan yang kedua gagal, perbezaannya ada di dalam pip dan bukan di rangkaian.

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