mitsuhiko/werkzeug — pull request #454 by jessaustin (2013-10-28 02:47:46+00:00)
Title: Use built-in **ssl** module

I had some issues trying to get SSL/TLS to work with python version 3.3. Consistent with this experience, **test_ssl_context_adhoc** fails for me on that version. #434 reports one of several issues I saw.

To fix this, I've ripped out all direct dependence on **OpenSSL.SSL**, and replaced that with python's built-in (since v2.6) **ssl** module. The **_SSLConnectionFix** class is gone completely, and a few related functions use **ssl.SSLContext** instead of **OpenSSL.SSL.Context**. I've left in everything from **OpenSSL.crypto**, since that seemed not to cause any problems. All tests pass on v3.3 with this update.

I don't know if this is the sort of thing the maintainers want. There are a few issues with what I've done here. First, the API has changed, since **ssl.SSLContext**s are not direct replacements for **OpenSSL.SSL.Context**s. Also, **load_ssl_context()** now takes an additional (optional) parameter, **protocol**. This parameter may be one of the *PROTOCOL_SSLv23* (the default), *PROTOCOL_SSLv3*, or *PROTOCOL_TLSv1* constants defined in **ssl**.

The existing code used the **OpenSSL.tsafe.Connection** class. Thread safety is probably important to *someone* who is using werkzeug to serve SSL, and I think I'm breaking that. **tsafe** is not the best-supported of modules, however, since it still has an **apply()** call, and **apply()** has been deprecated since v2.3. I'm open to suggestions: should we just rip off the **tsafe** code and drop it directly in werkzeug? Or should we not worry about it and tell everyone not to share **SSLContext**s among multiple threads?