On 2017-01-30 22:00, David Cournapeau wrote:
>
>
> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory@lukasa.co.uk
> <mailto:cory@lukasa.co.uk>> wrote:
>
>
>
> > On 30 Jan 2017, at 13:53, David Cournapeau <cournape@gmail.com <mailto:cournape@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.