[Python-Dev] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7
cory at lukasa.co.uk
Wed Jun 7 04:31:58 EDT 2017
> On 6 Jun 2017, at 18:49, 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.
Oh. This hadn’t occurred to me until just now, but doesn’t PyOpenSSL (or anything built on CFFI) just basically not run on Jython? Or am I mistaken?
> 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 <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).
Yeah, PEP 543 just basically assumes the stdlib’s testing of TLS doesn’t exist and that it’ll have to manufacture its own. Unfortunately, because it is attempting to abstract across many different implementations the tests will need to be fairly high-level: for example, there is no consistent way to discuss the actual size of the buffers in the buffer-based TLS implementation, and they are allowed to be unbounded buffers, so tests cannot validate that TLSWantReadError and TLSWantWriteError are ever actually raised: all they can do is run tests that will handle them in the even that they are raised and confirm the data is transferred appropriately.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev