Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

I wrote a first PEP draft:
https://github.com/python/peps/pull/272

Victor

2017-05-24 2:46 GMT+02:00 Victor Stinner :
> Hi,
>
> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
> 2.7? I can do the backport.
>
>   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
>
> Cory Benfield told me that it's a blocking issue for him to implement
> his PEP 543 -- A Unified TLS API for Python 2.7:
>
>   https://www.python.org/dev/peps/pep-0543/
>
> And I expect that if a new cool TLS API happens, people will want to
> use it on Python 2.7-3.6, not only on Python 3.7. Security evolves
> more quickly that the current Python release process, and people wants
> to keep their application secure.
>
> From what I understood, he wants to first implement an abstract
> MemoryBIO API (http://sans-io.readthedocs.io/ like API? I'm not sure
> about that), and then implement a socket/FD based on top of that.
> Maybe later, some implementations might have a fast-path using
> socket/FD directly.
>
> He described me his PEP and I strongly support it (sorry, I missed it
> when he posted it on python-dev), but we decided (Guido van Rossum,
> Christian Heimes, Cory Benfield and me, see the tweet below) to not
> put this in the stdlib right now, but spend more time on testing it on
> Twisted, asyncio, requests, etc. So publishing an implementation on
> PyPI was proposed instead. It seems like we agreed on a smooth plan
> (or am I wrong, Cory?).
>
>   https://twitter.com/VictorStinner/status/865467388141027329
>
> I'm quite sure that Twisted will love MemoryBIO on Python 2.7 as well,
> to implement TLS, especially on Windows using IOCP. Currently,
> external libraries (C extensions) are required.
>
> I'm not sure if the PEP 466 should be amended for that? Is a new PEP
> really needed? MemoryBIO/SSLObject are tiny. Nick (Coghlan): what do
> you think?
>
>   https://www.python.org/dev/peps/pep-0466/
>
> Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Nick Coghlan]

On 25 May 2017 at 21:24, Antoine Pitrou  wrote:
> The new TLS API wouldn't significantly improve security.  It's just a
> different API.

It isn't just a different API. It's an API with *backends for the
native TLS implementations on WIndows and Mac OS X*.

This means that instead of attempting to extract system certs and
inject them into a bundled copy of OpenSSL, it becomes viable to just
use the operating system provided security services and behave the
same was as any other native application (at least as far as secure
network connections are concerned).

Ideally, it would be good to get to a point where we can stop bundling
OpenSSL entirely on Windows and Mac OS X, such that OpenSSL CVEs stop
automatically turning into CPython CVEs, and we can instead delegate
the task of prompt network security stack updates to the OS provider,
the same way we do for non-Apple *nix systems.

Even if it isn't feasible to get Python 2.7 to that happy state by
2020, we may at least be able to get to a point where most routine TLS
connections from Python 2.7 applications are using an OS provided TLS
implementation, so their network security is less dependent on
receiving updates to the Python level components of their stack.

>> I also understood that getting access to system CA allows admins to
>> register their company CA and so avoid that users ignore the TLS warning
>> (unknown CA).
>
> System admins can add the company CA at the system level in the
> system's CA cert store, they have no need for a Python API.  Actually,
> they certainly don't want to modify every Python application to add a
> company CA.

The state of affairs that you're citing as undesirable is pretty much
the way things *currently* work. Most Python applications still won't
see system level certificates on Windows and Mac OS X, and they often
won't see them even on Linux and *BSD systems (unless they're running
directly in the system Python and using the system-provided requests
module (which gets patched to use the system certs rather than the
default Mozilla bundle).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Le 25 mai 2017 1:26 PM, "Antoine Pitrou"  a écrit :

System admins can add the company CA at the system level in the
system's CA cert store, they have no need for a Python API.


If I understood correctly, since the Python ssl module is unable to load
system CAs (at least on Python 2.7) on Windows and macOS, bundled CAs are
needed (like certfi package).

Actually,
they certainly don't want to modify every Python application to add a
company CA.


Yes.

Hum, maybe a short PEP is needed for Python 2.7 to clarify the indirect
advantages of the backport.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Antoine Pitrou]

On Tue, 23 May 2017 23:09:31 -0500
Victor Stinner  wrote:
> Le 23 mai 2017 20:43, "David Wilson"  a écrit :
> In which case, what is to prevent Requests from just depending on
> 
> pyOpenSSL as usual?
> 
> 
> From what I heard, pyOpenSSL development is slowing down, so I'm not sure
> that it's really safe and future-proof (TLS 1.3 anyone?).

So what? Python 2.7 isn't future-proof either...

> I'm still writing 2.7 code every day and would love to see it live a
> little longer, but accepting every feature request seems the wrong way
> to go - and MemoryBIO is a hard sell as a security enhancement, it's new
> functionality.

Agreed with this.

> You are true that they are new features. I disagree on the "accepting every
> feature" part: we are talking about two classes and it's restricted to
> security.

The new TLS API wouldn't significantly improve security.  It's just a
different API.

> I also understood that getting access to system CA allows admins to
> register their company CA and so avoid that users ignore the TLS warning
> (unknown CA).

System admins can add the company CA at the system level in the
system's CA cert store, they have no need for a Python API.  Actually,
they certainly don't want to modify every Python application to add a
company CA.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Nick Coghlan]

On 24 May 2017 at 14:27, Nathaniel Smith  wrote:
> On Tue, May 23, 2017 at 8:34 PM, David Wilson  wrote:
>> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
>>
>>> There are discussions around Requests unvendoring its dependencies
>>> thanks to the improved nature of pip. This might be a year of pretty
>>> big changes for Requests.
>>
>> In which case, what is to prevent Requests from just depending on
>> pyOpenSSL as usual?
>
> I thought that requests couldn't have any hard dependencies on C
> extensions, because pip vendors requests, and pip needs to be
> pure-python for bootstrapping purposes? Cory would know better than me
> though, so perhaps I'm wrong...

You're not wrong - even if requests itself stops bundling its
dependencies in its releases, pip will still need to bundle requests
and all its dependencies for bootstrapping purposes, which rules out a
hard dependency on PyOpenSSL (since even with manylinux1 available,
the wheel format doesn't offer 100% coverage of all environments where
pip will need to be bootstrapped).

>> I'm still writing 2.7 code every day and would love to see it live a
>> little longer, but accepting every feature request seems the wrong way
>> to go - and MemoryBIO is a hard sell as a security enhancement, it's new
>> functionality.
>
> IIUC, the security enhancement is indirect but real: on Windows/MacOS,
> Python's dependence on openssl is a security liability, and to get
> away from this we need Cory's new library that abstracts over
> different TLS implementations. But for applications to take advantage
> of this, they need to switch to using the new library. And before they
> can switch to using the new library, it needs to work everywhere. And
> for the new library to work on python 2 on unix, it needs MemoryBIO's
> in the stdlib – ideally using an interface that's as-close-as-possible
> to what they look like on python 3, so he doesn't have to implement
> totally different backends for py2 and py3, because Cory is already a
> hero for trying to make this happen and we don't want to waste any
> more of his time than necessary. So the end result is that if you have
> Python 2 code doing SSL/TLS on Windows/MacOS, and you want proper
> trust handling and prompt security updates, then MemoryBIO support is
> actually on the critical path for making that happen.

I believe you just wrote the "Rationale" section of the backport PEP :)

The other key aspect potentially worth mentioning is that upstream
approving the backport for a future 2.x maintenance release means that
downstream redistributors are also free to add it to their(/our) long
term support releases without introducing vendor specific divergences
(i.e. the feature being missing becomes just a typical "your Python is
too old, you'll have to install PyOpenSSL" problem, rather than a
"your Python is from the wrong redistributor" problem - while the
latter can still happen sometimes for various reasons, it's something
we collectively try to avoid).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Nathaniel Smith]

On Tue, May 23, 2017 at 8:34 PM, David Wilson  wrote:
> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
>
>> There are discussions around Requests unvendoring its dependencies
>> thanks to the improved nature of pip. This might be a year of pretty
>> big changes for Requests.
>
> In which case, what is to prevent Requests from just depending on
> pyOpenSSL as usual?

I thought that requests couldn't have any hard dependencies on C
extensions, because pip vendors requests, and pip needs to be
pure-python for bootstrapping purposes? Cory would know better than me
though, so perhaps I'm wrong...

> I'm still writing 2.7 code every day and would love to see it live a
> little longer, but accepting every feature request seems the wrong way
> to go - and MemoryBIO is a hard sell as a security enhancement, it's new
> functionality.

IIUC, the security enhancement is indirect but real: on Windows/MacOS,
Python's dependence on openssl is a security liability, and to get
away from this we need Cory's new library that abstracts over
different TLS implementations. But for applications to take advantage
of this, they need to switch to using the new library. And before they
can switch to using the new library, it needs to work everywhere. And
for the new library to work on python 2 on unix, it needs MemoryBIO's
in the stdlib – ideally using an interface that's as-close-as-possible
to what they look like on python 3, so he doesn't have to implement
totally different backends for py2 and py3, because Cory is already a
hero for trying to make this happen and we don't want to waste any
more of his time than necessary. So the end result is that if you have
Python 2 code doing SSL/TLS on Windows/MacOS, and you want proper
trust handling and prompt security updates, then MemoryBIO support is
actually on the critical path for making that happen.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Le 23 mai 2017 20:43, "David Wilson"  a écrit :
In which case, what is to prevent Requests from just depending on

pyOpenSSL as usual?


>From what I heard, pyOpenSSL development is slowing down, so I'm not sure
that it's really safe and future-proof (TLS 1.3 anyone?).

I'm still writing 2.7 code every day and would love to see it live a
little longer, but accepting every feature request seems the wrong way
to go - and MemoryBIO is a hard sell as a security enhancement, it's new
functionality.


You are true that they are new features. I disagree on the "accepting every
feature" part: we are talking about two classes and it's restricted to
security. Security matters for me and for practical reasons explained in
thid thread, we need the two classes.

Cory's PEP adds long awaited features (bugfixes?) to TLS, like getting
access to root certificates on macOS and Windows. Not having to provide our
own set of root certificates would make applications hlobally more secure.
It's ttricky to update certificates. It happens that root CA are revoked
after aa break-in or because the CA is no more trusted.

I also understood that getting access to system CA allows admins to
register their company CA and so avoid that users ignore the TLS warning
(unknown CA).

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Cory Benfield]

> On 23 May 2017, at 20:34, David Wilson  wrote:
> 
> On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:
> 
>> There are discussions around Requests unvendoring its dependencies
>> thanks to the improved nature of pip. This might be a year of pretty
>> big changes for Requests.
> 
> In which case, what is to prevent Requests from just depending on
> pyOpenSSL as usual?

Requests currently does not depend on PyOpenSSL on 2.7: it’s simply an optional 
dependency for those who need it.

Cory
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Le 23 mai 2017 17:49, "Alex Gaynor"  a écrit :

I'm +1 on this, I even wrote the patch: https://bugs.python.org/issue22559
:-) If you're interested in making sure that still applies and tests still
pass, I'd be a big fan.


Oh sorry, I wasn't aware of that one. Sure, will do.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Le 23 mai 2017 19:46, "Nick Coghlan"  a écrit :
(...) to the RHEL system Python by switching the default

behaviour for new installs to be to verify SSL/TLS certificates
against the system trust store


Awesome! Security, I see security everywhere!

Stay safe,
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[David Wilson]

On Tue, May 23, 2017 at 06:13:17PM -0700, Cory Benfield wrote:

> There are discussions around Requests unvendoring its dependencies
> thanks to the improved nature of pip. This might be a year of pretty
> big changes for Requests.

In which case, what is to prevent Requests from just depending on
pyOpenSSL as usual?

I'm still writing 2.7 code every day and would love to see it live a
little longer, but accepting every feature request seems the wrong way
to go - and MemoryBIO is a hard sell as a security enhancement, it's new
functionality.


David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Nick Coghlan]

On 24 May 2017 at 10:46, Victor Stinner  wrote:
> Hi,
>
> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
> 2.7? I can do the backport.
>
>   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO

+1 from me - the last SSL module resync to 2.7 was from 3.4, and
bringing them back closer to feature parity again is genuinely
beneficial in ensuring the Python ecosystem is able to keep up with
evolving network security standards.

Guido requested back when PEP 466 was written that any further
security backports come with their own PEP in order to clearly
communicate what's being backported, and the "What's New in Python 2.7
Maintenance Releases?" section is organised accordingly.

However, the "Why?" section in such a PEP can be a lot shorter than it
was for the original precedent setting one, since it only needs to
describe the benefits of the specific security features being
backported, rather than having to make the case for the idea of
backporting security features in general.

Cheers,
Nick.

P.S. Somewhat related, folks may be interested to know that the
upcoming RHEL 7.4 release finally completes the process of backporting
PEPs 466 & 476 to the RHEL system Python by switching the default
behaviour for new installs to be to verify SSL/TLS certificates
against the system trust store:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/7.4_Release_Notes/new_features_compiler_and_tools.html

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Cory Benfield]

> On 23 May 2017, at 17:58, Victor Stinner  wrote:
> 
> 2017-05-23 19:54 GMT-05:00 Cory Benfield :
>> In the absence of a Python 2.7 backport, Requests is required to basically 
>> use the same solution that Twisted currently does: namely, a mandatory 
>> dependency on PyOpenSSL.
> 
> Last time I looked at requests, it embedded all its dependencies. I
> don't like the idea of embedding PyOpenSSL…

There are discussions around Requests unvendoring its dependencies thanks to 
the improved nature of pip. This might be a year of pretty big changes for 
Requests.

Cory

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

2017-05-23 19:54 GMT-05:00 Cory Benfield :
> In the absence of a Python 2.7 backport, Requests is required to basically 
> use the same solution that Twisted currently does: namely, a mandatory 
> dependency on PyOpenSSL.

Last time I looked at requests, it embedded all its dependencies. I
don't like the idea of embedding PyOpenSSL...

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Well, things evolved recently. asyncio is getting more popular, TLS
became even more important, and pyOpenSSL is not more evolving (from
what I heard from his maintainer, Hynek). Does Twister still use
pyOpenSSL?

I like the idea of putting more security stuff into Python to ease
maintainance of applications and try to make it as security as
possible. Python has more resources (ex: CI) than some smaller
projects.

Victor

2017-05-23 19:49 GMT-05:00 Alex Gaynor :
> I'm +1 on this, I even wrote the patch: https://bugs.python.org/issue22559
> :-) If you're interested in making sure that still applies and tests still
> pass, I'd be a big fan.
>
> In addition to all the benefits you mentioned, it also substantially reduces
> the diff between 2.7 and 3.x (or at least it did when I originally wrote
> it).
>
> Cheers,
> Alex
>
> On Tue, May 23, 2017 at 8:46 PM, Victor Stinner 
> wrote:
>>
>> Hi,
>>
>> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
>> 2.7? I can do the backport.
>>
>>   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
>>
>> Cory Benfield told me that it's a blocking issue for him to implement
>> his PEP 543 -- A Unified TLS API for Python 2.7:
>>
>>   https://www.python.org/dev/peps/pep-0543/
>>
>> And I expect that if a new cool TLS API happens, people will want to
>> use it on Python 2.7-3.6, not only on Python 3.7. Security evolves
>> more quickly that the current Python release process, and people wants
>> to keep their application secure.
>>
>> From what I understood, he wants to first implement an abstract
>> MemoryBIO API (http://sans-io.readthedocs.io/ like API? I'm not sure
>> about that), and then implement a socket/FD based on top of that.
>> Maybe later, some implementations might have a fast-path using
>> socket/FD directly.
>>
>> He described me his PEP and I strongly support it (sorry, I missed it
>> when he posted it on python-dev), but we decided (Guido van Rossum,
>> Christian Heimes, Cory Benfield and me, see the tweet below) to not
>> put this in the stdlib right now, but spend more time on testing it on
>> Twisted, asyncio, requests, etc. So publishing an implementation on
>> PyPI was proposed instead. It seems like we agreed on a smooth plan
>> (or am I wrong, Cory?).
>>
>>   https://twitter.com/VictorStinner/status/865467388141027329
>>
>> I'm quite sure that Twisted will love MemoryBIO on Python 2.7 as well,
>> to implement TLS, especially on Windows using IOCP. Currently,
>> external libraries (C extensions) are required.
>>
>> I'm not sure if the PEP 466 should be amended for that? Is a new PEP
>> really needed? MemoryBIO/SSLObject are tiny. Nick (Coghlan): what do
>> you think?
>>
>>   https://www.python.org/dev/peps/pep-0466/
>>
>> Victor
>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Cory Benfield]

> On 23 May 2017, at 17:46, Victor Stinner  wrote:
> 
> 
> He described me his PEP and I strongly support it (sorry, I missed it
> when he posted it on python-dev), but we decided (Guido van Rossum,
> Christian Heimes, Cory Benfield and me, see the tweet below) to not
> put this in the stdlib right now, but spend more time on testing it on
> Twisted, asyncio, requests, etc. So publishing an implementation on
> PyPI was proposed instead. It seems like we agreed on a smooth plan
> (or am I wrong, Cory?).

Yes, this is correct. There are plans afoot to look at moving Requests to a 
more event-loop-y model, and doing so basically mandates a MemoryBIO. In the 
absence of a Python 2.7 backport, Requests is required to basically use the 
same solution that Twisted currently does: namely, a mandatory dependency on 
PyOpenSSL.

I’m very much +1 on this.

Cory
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Alex Gaynor]

I'm +1 on this, I even wrote the patch: https://bugs.python.org/issue22559
:-) If you're interested in making sure that still applies and tests still
pass, I'd be a big fan.

In addition to all the benefits you mentioned, it also substantially
reduces the diff between 2.7 and 3.x (or at least it did when I originally
wrote it).

Cheers,
Alex

On Tue, May 23, 2017 at 8:46 PM, Victor Stinner 
wrote:

> Hi,
>
> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
> 2.7? I can do the backport.
>
>   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
>
> Cory Benfield told me that it's a blocking issue for him to implement
> his PEP 543 -- A Unified TLS API for Python 2.7:
>
>   https://www.python.org/dev/peps/pep-0543/
>
> And I expect that if a new cool TLS API happens, people will want to
> use it on Python 2.7-3.6, not only on Python 3.7. Security evolves
> more quickly that the current Python release process, and people wants
> to keep their application secure.
>
> From what I understood, he wants to first implement an abstract
> MemoryBIO API (http://sans-io.readthedocs.io/ like API? I'm not sure
> about that), and then implement a socket/FD based on top of that.
> Maybe later, some implementations might have a fast-path using
> socket/FD directly.
>
> He described me his PEP and I strongly support it (sorry, I missed it
> when he posted it on python-dev), but we decided (Guido van Rossum,
> Christian Heimes, Cory Benfield and me, see the tweet below) to not
> put this in the stdlib right now, but spend more time on testing it on
> Twisted, asyncio, requests, etc. So publishing an implementation on
> PyPI was proposed instead. It seems like we agreed on a smooth plan
> (or am I wrong, Cory?).
>
>   https://twitter.com/VictorStinner/status/865467388141027329
>
> I'm quite sure that Twisted will love MemoryBIO on Python 2.7 as well,
> to implement TLS, especially on Windows using IOCP. Currently,
> external libraries (C extensions) are required.
>
> I'm not sure if the PEP 466 should be amended for that? Is a new PEP
> really needed? MemoryBIO/SSLObject are tiny. Nick (Coghlan): what do
> you think?
>
>   https://www.python.org/dev/peps/pep-0466/
>
> Victor
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

Hi,

Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
2.7? I can do the backport.

  https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO

Cory Benfield told me that it's a blocking issue for him to implement
his PEP 543 -- A Unified TLS API for Python 2.7:

  https://www.python.org/dev/peps/pep-0543/

And I expect that if a new cool TLS API happens, people will want to
use it on Python 2.7-3.6, not only on Python 3.7. Security evolves
more quickly that the current Python release process, and people wants
to keep their application secure.

>From what I understood, he wants to first implement an abstract
MemoryBIO API (http://sans-io.readthedocs.io/ like API? I'm not sure
about that), and then implement a socket/FD based on top of that.
Maybe later, some implementations might have a fast-path using
socket/FD directly.

He described me his PEP and I strongly support it (sorry, I missed it
when he posted it on python-dev), but we decided (Guido van Rossum,
Christian Heimes, Cory Benfield and me, see the tweet below) to not
put this in the stdlib right now, but spend more time on testing it on
Twisted, asyncio, requests, etc. So publishing an implementation on
PyPI was proposed instead. It seems like we agreed on a smooth plan
(or am I wrong, Cory?).

  https://twitter.com/VictorStinner/status/865467388141027329

I'm quite sure that Twisted will love MemoryBIO on Python 2.7 as well,
to implement TLS, especially on Windows using IOCP. Currently,
external libraries (C extensions) are required.

I'm not sure if the PEP 466 should be amended for that? Is a new PEP
really needed? MemoryBIO/SSLObject are tiny. Nick (Coghlan): what do
you think?

  https://www.python.org/dev/peps/pep-0466/

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com