You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for SSL_CERT_FILE, REQUESTS_CA_BUNDLE, and CURL_CA_BUNDLE #306
Part of #33 these three environment variables all have the same behavior, to specify where a CA bundle is if none are specified by default and trust_env is True.
We should check the three environment variables in the order above, as SSL_CERT_FILE is a PEP and a standard whereas the other are products of other projects.
If multiple are set and that file doesn't exist we should skip it and try the next environment variable.
We'll also have to document these environment variables within docs/environment.md.
I suppose REQUEST_CA_BUNDLE is a Requests-specific environment variable, right? The main argument to keeping it is compatibility with Requests, but now that we’ve got SSL_CERT_FILE as a PEP standard it might be one of those changes we could document along with the more modern alternative we suggest.
We could always walk back from that point to add support requests and curl style env vars in addition, but I don't think it's obvious if we want to do that or not.
One data point: to get async/await support, we switched from requests to httpx for a production service at work today, and we had to change this environment variable. It would be nice if requests supported SSL_CERT_FILE and SSL_CERT_DIR but it doesn't: psf/requests#2903 (comment).
Reacted by Florimond Manca, Kim Christie, Aaron and CzBiX
Activity
lovelydinosaur commentedon Sep 3, 2019
Coming back to this again - do we really want all three of those environment variables, or should we be trying to keep things a bit more narrow?
I know I referenced REQUESTS_CA_BUNDLE in #33 in the first place, but it's not so clear to me now if we should be trying to keep it slimmer.
florimondmanca commentedon Sep 3, 2019
I suppose REQUEST_CA_BUNDLE is a Requests-specific environment variable, right? The main argument to keeping it is compatibility with Requests, but now that we’ve got SSL_CERT_FILE as a PEP standard it might be one of those changes we could document along with the more modern alternative we suggest.
lovelydinosaur commentedon Sep 3, 2019
Yeah, I think our starting point should be the PEP - https://www.python.org/dev/peps/pep-0476/#trust-database - Ie. let's support
SSL_CERT_FILEandSSL_CERT_DIR.We could always walk back from that point to add support requests and curl style env vars in addition, but I don't think it's obvious if we want to do that or not.
StephenBrown2 commentedon Sep 3, 2019
Definitely in support of only
SSL_CERT_FILEandSSL_CERT_DIR.gdhameeja commentedon Sep 7, 2019
I would like to work on this.
sethmlarson commentedon Sep 7, 2019
@gdhameeja This issue is already being worked on by @cansarigol, you can take a look at the PR here if you'd like to give comments: #307
pquentin commentedon Oct 13, 2020
One data point: to get async/await support, we switched from requests to httpx for a production service at work today, and we had to change this environment variable. It would be nice if requests supported
SSL_CERT_FILEandSSL_CERT_DIRbut it doesn't: psf/requests#2903 (comment).