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

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

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

From what I heard, pyOpenSSL development is slowing down, so I'm not sure

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? 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

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 | ncoghlan@gmail.com | Brisbane, Australia

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 | ncoghlan@gmail.com | Brisbane, Australia

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