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

["Martin v. Löwis"]

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