On 2 February 2017 at 10:38, Cory Benfield <c...@lukasa.co.uk> wrote: > This PEP would define a standard TLS interface in the form of a collection of > abstract base classes. This interface would allow Python implementations and > third-party libraries to provide bindings to TLS libraries other than OpenSSL > that can be used by tools that expect the interface provided by the Python > standard library, with the goal of reducing the dependence of the Python > ecosystem on OpenSSL.
Most of the PEP went over my head, but what I understood looks well thought out and sensible. Overall I'm +1 on this. One thing that wasn't clear to me was the backward compatibility implications. Will the existing ssl module and its API be retained, or will it be modified/deprecated? Will Windows/OSX distributions of Python ultimately stop shipping with OpenSSL included? From an end user POV, I won't care (high level modules like asyncio, urllib[1], http.client etc will be updated to transparently use the new infrastructure) so I accept that this is something of an "internal" and/or library author concern. Thanks for putting the effort into this - people like me rely on "other people" getting the security stuff right, and I appreciate the work that those others like yourself put in for me. Paul [1] urllib wasn't actually a module noted as needing change. Was that an omission, or is it simply because it defers the TLS stuff to the lower levels like http.client? _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
