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

[Jim Baker]

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.

- Jim

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 _tls_bootstrap;
> > _tls_bootstrap.monkeypatch_ssl()" 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 _tls_bootstrap.py and __tls_bootstrap.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>