[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 23 00:08:48 CET 2014

Am 22.03.14 23:39, schrieb Ned Deily:

Regarding the python.org binary installers, I think past practice has been for us to update third-party libraries as necessary in maintenance releases when there is good cause and with the concurrence of the release manager, so I don't see this as a big issue. For the OS X binary installer, the issue for OpenSSL has been that we dynamically link to the system-supplied OpenSSL libraries and that, for various reasons, Apple has deprecated (and frozen at non-current OpenSSL releases) the use of those libraries in favor of their own security frameworks. So, for multiple reasons, including the risk that OpenSSL may be dropped from an upcoming major release of OS X, we need to start supplying our own version with all OS X binary installers. That's the plan regardless of the outcome of this PEP.

The Windows case is similar but different. I also update OpenSSL releases between Python bug fix releases, but only to OpenSSL bug fix releases (likewise for all other third party software). So 2.7 uses 0.9.8 (currently 0.9.8y), 3.3 and 3.4 use 1.0.1 (currently 1.0.1e).

I still wish it was possible to drop OpenSSL altogether on both OSX and Windows, and use the vendor TLS libraries instead. This would reduce the maintenance burden, and might even improve performance. However, it's getting difficult since the ssl module exposes more and more OpenSSL API as-is (rather than trying to provide an abstraction).

For Windows, this approach was unfortunately hopeless as long as we had to support XP. Now that Vista becomes the baseline, I hope I can try to provide much of the ssl module natively using CryptoAPI.

Regards, Martin

More information about the Python-Dev mailing list