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

Jim Baker jim.baker at python.org
Tue Jun 6 13:49:49 EDT 2017

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.

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).

The problem we have seen with Jython supporting similar functionality in the past in socket/select/ssl is not the happy path aspects like what ssl_io_loop tests, but underdocumented/undertested error states. So what benefits SChannel support, for example, should benefit Jython 3's implementation that would use Java's counterpart to SSLObject, SSLEngine. That would be a very good outcome of these proposed PEPs.

On Tue, Jun 6, 2017 at 4:08 AM, Nathaniel Smith <njs at pobox.com> wrote:

On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > The reason this kind of approach is really attractive to > redistributors from a customer risk management perspective is that > like gevent's monkeypatching of synchronous networking APIs, it's > opt-in at runtime, so the risk of our accidentally inflicting it on > a customer that doesn't want it and doesn't need it is almost exactly > zero - if none of their own code includes the "import tlsbootstrap; > tlsbootstrap.monkeypatchssl()" invocation and none of their > dependencies start enabling it as an implicit side effect of some > other operation, they'll never even know the enhancement is there. > Instead, the compatibility risks get concentrated in the applications > relying on the bootstrapping API, since the monkeypatching process is > a potentially new source of bugs that don't exist in the more > conventional execution models.

OK. To unpack that, I think it would mean: 2.7's ssl.py and ssl.c remain exactly as they are. _We create a new tlsbootstrap.py and tlsbootstrap.c, which start out as ~copies of the current ssl.py and ssl.c code in master. (Unfortunately the SSLObject code can't just be separated out from ssl.c into a new file, because the implementations of SSLObject and SSLSocket are heavily intertwined.) Then the copied files are hacked up to work in this monkeypatching context (so that e.g. instead of defining the SSLError hierarchy in C code, it gets imported from the main ssl.py). So: we end up with two copies of the ssl code in the py27 tree, both diverged from the copy that in the py3 tree, in different ways. I know that the ssl maintainers won't be happy about this given that keeping the py2 and py3 code similar is an ongoing issue and was one of the stated advantages of backporting SSLObject, but I don't know whether it's a showstopper or not; it'd be good to hear their perspective. -n -- Nathaniel J. Smith -- https://vorpus.org

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ jbaker%40zyasoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170606/aab2f5c0/attachment.html>

More information about the Python-Dev mailing list