On 01Jun2017 1010, Nathaniel Smith wrote: > I believe that for answering this question about the ssl module, it's > really only Linux users that matter, since pip/requests/everyone else > pushing for this only want to use ssl.MemoryBIO on Linux. Their plan on > Windows/MacOS (IIUC) is to stop using the ssl module entirely in favor > of new ctypes bindings for their respective native TLS libraries. > > (And yes, in principle it might be possible to write new ctypes-based > bindings for openssl, but (a) this whole project is already teetering on > the verge of being impossible given the resources available, so adding > any major extra deliverable is likely to sink the whole thing, and (b) > compared to the proprietary libraries, openssl is *much* harder and > riskier to wrap at the ctypes level because it has > different/incompatible ABIs depending on its micro version and the > vendor who distributed it. This is why manylinux packages that need > openssl have to ship their own, but pip can't and shouldn't ship its own > openssl for many hopefully obvious reasons.) How much of a stop-gap would it be (for Windows at least) to override OpenSSL's certificate validation with a call into the OS? This leaves most of the work with OpenSSL, but lets the OS say yes/no to the certificates based on its own configuration. For Windows, this is under 100 lines of C code in (probably) _ssl, and while I think an SChannel based approach is the better way to go long-term,[1] offering platform-specific certificate validation as the default in 2.7 is far more palatable than backporting new public API. I can't speak to whether there is an equivalent function for Mac (validate a certificate chain given the cert blob). Cheers, Steve [1]: though I've now spent hours looking at it and still have no idea how it's supposed to actually work...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4