[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

Nathaniel Smith njs at pobox.com
Wed Jun 7 04:56:01 EDT 2017

On Tue, Jun 6, 2017 at 10:49 AM, Jim Baker <jim.baker at python.org> wrote:
> With Nick's suggestion of _tls_bootstrap, this has certainly become more
> complicated. I'm still thinking of the ramifications for future Jython 2.7
> support, if Python dev goes down this path. It still seems easier to me to
> avoid exposing the SSLObject/MemoryBIO model to 2.7 and instead concentrate
> on just having native TLS support. Yes, this might require more work than a
> simple backport, but everyone is resource constrained, not just the Requests
> or Jython teams.

Yeah, presumably the preferred way to do PEP 543 on Jython would be to
have a native backend based on javax.net.ssl.SSLEngine. Not sure how
that affects the MemoryBIO discussion – maybe it means that Jython
just doesn't need a MemoryBIO backport in the stdlib ssl module,
because everyone who might use it will find themselves using SSLEngine

> My concrete suggestion is that any work on PEP 543 will benefit from
> improving the testing currently found in test_ssl as part of its
> implementation. For a variety of reasons, test functions like ssl_io_loop
> (https://github.com/python/cpython/blob/master/Lib/test/test_ssl.py#L1691)
> avoid asserting more than it can properly manage the framing of
> wrapped/unwrapped data, so for example one doesn't want to state explicitly
> when SSL_ERROR_WANT_READ would be called (too much white box at that point).
> On the other hand, the lack of unit testing of, for example, SSLObject.read,
> but instead only doing at the functional test level, means that there's
> nothing explicit testing "will raise an SSLWantReadError if it needs more
> data than the incoming BIO has available" (per the docs), or similar use of
> signaling (SSLEOFError comes to mind).

Another testing challenge is that the stdlib ssl module has no way to
trigger a renegotiation, and therefore there's no way to write tests
to check that it properly handles a renegotiation, even though
renegotiation is by far the trickiest part of the protocol to get
right. (In particular, renegotiation is the only case where attempting
to read can give WantWrite and vice-versa.)


Nathaniel J. Smith -- https://vorpus.org

More information about the Python-Dev mailing list