<div dir="ltr"><div><div><div><div><div><div><div>Hi,<br><br></div>I am managing the team responsible for providing python packaging at Enthought, and I would like to make sure we are providing a good (and secure) out of the box experience for SSL.<br><br></div>My understanding is that PEP 476 is the latest PEP that concerns this issue, and that PEP recommends using the system store: <a href="https://www.python.org/dev/peps/pep-0476/#trust-database">https://www.python.org/dev/peps/pep-0476/#trust-database</a>. But looking at binary python distributions from <a href="http://python.org">python.org</a>, that does not seem to a.ways be the case. I looked at the following:<br><br></div>* 3.5.3 from <a href="http://python.org">python.org</a> for OS X (64 bits): this uses the old, system openssl<br></div>* 3.6.0 from <a href="http://python.org">python.org</a> for OS X: this embeds a recent openssl, but ssl seems to be configured to use non existing paths (ssl..get_default_verify_paths()), and indeed, cert validation seems to fail by default with those installers<br></div>* 3.6.0 from <a href="http://python.org">python.org</a> for windows: I have not found how the ssl module finds the certificate, but certification seems to work<br><br></div>Are there any official recommendations for downstream packagers beyond PEP 476 ? Is it "acceptable" for downstream packagers to patch python's default cert locations ?<br><br></div>David<br></div>