On 2017-01-30 22:00, David Cournapeau wrote: > > > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory at lukasa.co.uk > <mailto:cory at lukasa.co.uk>> wrote: > > > > > On 30 Jan 2017, at 13:53, David Cournapeau <cournape at gmail.com <mailto:cournape at gmail.com>> wrote: > > > > Are there any official recommendations for downstream packagers beyond PEP 476 ? Is it "acceptable" for downstream packagers to patch python's default cert locations ? > > There *are* no default cert locations on Windows or macOS that can > be accessed by OpenSSL. > > I cannot stress this strongly enough: you cannot provide a > platform-native certificate validation logic for Python *and* use > OpenSSL for certificate validation on Windows or macOS. (macOS can > technically do this when you link against the system OpenSSL, at the > cost of using a catastrophically insecure version of OpenSSL.) > > > Ah, thanks, that's already useful information. > > Just making sure I understand: this means there is no way to use > python's SSL library to use the system store on windows, in particular > private certifications that are often deployed by internal ITs in large > orgs ? That works with CPython because we get all trust anchors from the cert store. However Python is not able to retrieve *additional* certificates. A new installation of Windows starts off with a minimal set of trust anchors. Chrome, IE and Edge use the proper APIs. There is no way to get internal CA on macOS with 3.6, with certifi, or with self-build OpenSSL. Christian
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