pip --cert flag does not overwrite REQUESTS_CA_BUNDLE environment variable

Description

pip does not overwrite the certificate provided in the REQUESTS_CA_BUNDLE environment variable when using pip install --cert <cert_file> <package>.

I assume this has to do with pip using urllib3 or something like that, which reads in the environment variables for certificates, proxies, and other SSL-related things.

Expected behavior

pip should change the order of operations, allowing the --cert flag to overwrite the environment variable REQUESTS_CA_BUNDLE, among others.

Also, pip install -vvv should probably give a bit more network information besides just “new HTTPS connection to <index_url>:443”. Having the most verbose version output the certificate path and environment variables used (think curl -v) seems important for a network-bound package manager. There’s no actual way to debug this without having a bad certificate.

pip version

21.1.3

Python version

3.9.5

OS

MacOS 10.15.7

How to Reproduce

Need two certificate files, one that works—good_cert.pem (/etc/ssl/cert.pem should work on most systems)—and one that doesn’t—bad_cert.pem (you can make a self-signed certificate with openssl req).

Run:

export REQUESTS_CA_BUNDLE=bad_cert.pem
python3 -m pip install --force-reinstall pip --cert=good_cert.pem

to get an error

Alternatively:

export REQUESTS_CA_BUNDLE=good_cert.pem
python3 -m pip install --force-reinstall pip --cert=bad_cert.pem

runs fine.

Output

WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))': /simple/pip/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))': /simple/pip/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))': /simple/pip/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))': /simple/pip/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))': /simple/pip/
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/pip/ (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)'))) - skipping
ERROR: Could not find a version that satisfies the requirement pip (from versions: none)
ERROR: No matching distribution found for pip

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[uranusjr]

For the developers, I would still recommend making the verbose-iest output at least a teeny bit more descriptive in terms of network connection settings.

A pull request adding some debug output would be very welcomed, since I think the main reason why there’s very little logged currently is because we don’t really know what to log. None of the active pip maintainers have much experience working with those big-corp setups, and the big corps give close to zero feedback on them (which also means your report is extremely valuable, and any contribution would be greatly appreciated!)

[pfmoore]

pip vendors requests (we vendor all of our dependencies, as we have to be able to work before they are installed…)