[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 (original) (raw)

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 tlsbootstrap, 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 instead.

My concrete suggestion is that any work on PEP 543 will benefit from improving the testing currently found in testssl as part of its implementation. For a variety of reasons, test functions like sslioloop (https://github.com/python/cpython/blob/master/Lib/test/testssl.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 SSLERRORWANTREAD 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.)

-n

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

More information about the Python-Dev mailing list