Closed jasongrout closed 9 years ago
I think it would probably make more sense to preserve the boolean type of verify_ssl, and introduce another string option for the certificate file.
@groutr - you asked me to CC you on this.
@jasongrout, would you be willing to test the proposed fix? I don't have a way to test it.
Thanks! We don't need the client-side SSL capabilities (e.g., http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/). What we need is to be able to specify trusted root certificates to verify the server. In other words, we need to be able to use the option in requests to pass in a path to the verify argument of the session.get
command.
Maybe it makes sense to just have the verify_ssl
parameter take a path, and not just a boolean. That would more cleanly map to the requests api. Then the patch literally just becomes removing the bool
call when getting the parameter, and maybe updating documentation?
(the reason corporate proxies need to specify trusted root certificates is that they deliberately man-in-the-middle ssl certificates to be able to filter and check ssl traffic. Being able to specify a trusted cert means that we can tell the request that yes, we know the ssl certificate doesn't check out, but we explicitly trust the corporate certificate too.)
oh...I misunderstood your original request.
@jasongrout, new pull request. I misread the docs too. ssl_verify
can now take an arbitrary value and pass it to session.get. You have to set the option manually in .condarc
I'm wondering if we should do any sanity checks (like make sure the string points to a file or directory).
Good question. I don't know what the standard is for checking things in Conda. Presumably if the file doesn't exist, a relevant error will come out of requests, though. Does setting it to False still work? I guess this does change the behavior, since other falsey values would have been False before. Presumably somewhere in some docs the change should be noted?
You're correct, we do want to check if it evaluates to an accepted boolean value ('on', 'true', 'yes' should all evaluate to True, the antonyms to False, and everything else we assume is a filename and pass directly to requests). Let me know if this is working for your use case, then I'll update the docs before merging.
I don't know how to install this locally to check to see if it works. I suppose I could manually apply the patch, but is there some other more supported way to install a patched conda temporarily?
The easiest way is to use PYTHONPATH=. conda install ...
.
Yep, this seems to work great. Thanks!
This works now, courtesy of #1432
what is the path that ssl_verify uses to look for the certficate?
I don't remember for sure, but I think a relative path would be relative to the directory in which conda is run, so IIRC, I always specified an absolute path.
Hi there, thank you for your contribution to Conda!
This issue has been automatically locked since it has not had recent activity after it was closed.
Please open a new issue if needed.
Currently the
.condarc
file'sverify_ssl
key seems to be just a boolean (see https://github.com/conda/conda/blob/master/conda/config.py#L70). If a proxy is in the way, the only option [1] is to turn off ssl verification. However, requests supports setting the verify_ssl setting to a file of trusted certificates (see http://docs.python-requests.org/en/latest/user/advanced/#ssl-cert-verification). Can we allow the .condarc verify_ssl setting to take a path to a certificate file? Then we don't have to forego the ssl verification, but we can still trust the proxy's man-in-the-middle certificate.[1] Well, technically we can also set the REQUESTS_CA_CERTIFICATE environment variable to have requests trust a specific list of certificates, but that requires (a) digging into the conda source to see that it is using requests, and then (b) digging into the requests docs to see that you can set the environment variable. It'd be much cleaner if the .condarc setting just supported the path too.