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

> On 9 Jun 2017, at 20:54, Donald Stufft wrote: > > > All that being said, if someone *does* want pip to use WinHTTP, requests > provides a mechanism where you can plug in your own network handling code, so > someone could write a requests-winhttp adapter that did that, and

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

> On Jun 9, 2017, at 3:41 PM, Steve Dower wrote: > > On 09Jun2017 1118, Donald Stufft wrote: >> A ensuressl style module that tries to install an OpenSSL module is actually >> fairly hard to do securely. The fundamental issue being that fetching a file >> securely from

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

> On 9 Jun 2017, at 20:41, Steve Dower wrote: > > These are totally fine for implementing a requests-like API that relies on > system configuration for HTTPS connections. They are not sufficient for > building a server, but they should be sufficient for downloading the

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

On 09Jun2017 1118, Donald Stufft wrote: A ensuressl style module that tries to install an OpenSSL module is actually fairly hard to do securely. The fundamental issue being that fetching a file securely from the network before you have the primary tool for fetching things securely from a

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

On Jun 09, 2017, at 08:43 PM, Nick Coghlan wrote: >So honestly, I'd be +1 for either approach: > >- stdlib backport to make dual-stack maintenance easier for the >current volunteers, and we'll see how things work out on the >ease-of-adoption front As I've said, I'm okay with this approach as

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

> On Jun 9, 2017, at 1:07 PM, Steve Dower wrote: > > On 09Jun2017 0343, Nick Coghlan wrote: >> So honestly, I'd be +1 for either approach: >> - stdlib backport to make dual-stack maintenance easier for the >> current volunteers, and we'll see how things work out on the

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

On 09Jun2017 0343, Nick Coghlan wrote: So honestly, I'd be +1 for either approach: - stdlib backport to make dual-stack maintenance easier for the current volunteers, and we'll see how things work out on the ease-of-adoption front - PyPI backport to make 2.7 adoption easier, and we'll continue

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

> On Jun 9, 2017, at 6:43 AM, Nick Coghlan wrote: > > OTOH, if the aim is to make the change now, so it gets into Ubuntu > 18.04, with a view to projects only starting to fully rely on it in > mid-to-late 2018 or so? That timeline might actually work, and this > approach has

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

On 9 June 2017 at 05:51, Donald Stufft wrote: > And the downside here is pretty small honestly? Unfortunately, one of the downsides is "Doesn't provide any clearly compelling benefits to users of LTS distributions, so even those of us in a position to advocate for such

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

> On 8 Jun 2017, at 21:17, Donald Stufft wrote: > >> >> On Jun 8, 2017, at 3:57 PM, Steve Dower > > wrote: >> >> Awesome, this is exactly what I needed to see. >> >> What if Python 2.7 just exposed the OpenSSL

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

> On Jun 8, 2017, at 3:57 PM, Steve Dower wrote: > > On 08Jun2017 1237, Donald Stufft wrote: >> The basic yak stak here is: >> * PEP 543 should be the future, it is a much much better way of handling TLS >> than our current ssl module is. >> * Cory can’t spend his work

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

On 08Jun2017 1237, Donald Stufft wrote: The basic yak stak here is: * PEP 543 should be the future, it is a much much better way of handling TLS than our current ssl module is. * Cory can’t spend his work time on PEP 543 unless he can say it is useful for requests. * In order for PEP 543 to

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

> On Jun 8, 2017, at 3:37 PM, Donald Stufft wrote: > > So basically back porting MemoryBio unlocks two important things for the > health of the Python ecosystem: > > * Allows forward progress on PEP 543, which provides a wealth of great > benefits like using the platform

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

> On Jun 8, 2017, at 12:40 PM, Steve Dower wrote: > > I'm just going to straight up admit that I've lost track of the point of this > thread. > > It sounds like we don't *need* to backport any of ssl into the Python 2.7 > standard library, as long as we can bundle a

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

On 8 June 2017 at 17:40, Steve Dower wrote: > I'm just going to straight up admit that I've lost track of the point of > this thread. You have my sympathies - I'm not really following it either :-( > It sounds like we don't *need* to backport any of ssl into the Python

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

I'm just going to straight up admit that I've lost track of the point of this thread. It sounds like we don't *need* to backport any of ssl into the Python 2.7 standard library, as long as we can bundle a 3rd-party backport for pip? I assume that, at a high level, the operation needed is to

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

On 8 June 2017 at 21:30, Victor Stinner wrote: > Maybe the intent of my PEP is unclear: the goal is not to allow > Requests to require MemoryBIO, but to get a wide adoption of a future > implementation of the new TLS API (PEP). IMHO having an implementation > working on

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

On Thu, 8 Jun 2017 09:30:37 +0100 Cory Benfield wrote: > > Ah, yes, we do. In our defense, this is the semantic of the listen > syscall,[...] According to POSIX, the backlog is only a hint, i.e. Jython is probably ok in not observing its value: """The backlog argument

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

Maybe the intent of my PEP is unclear: the goal is not to allow Requests to require MemoryBIO, but to get a wide adoption of a future implementation of the new TLS API (PEP). IMHO having an implementation working on the latest Python 2.7 version should make it possible to use it on some kinds of

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

> On Jun 8, 2017, at 6:36 AM, Victor Stinner wrote: > > 2017-06-08 10:30 GMT+02:00 Cory Benfield : >> This is what I was worried about. Moving to require PyOpenSSL *also* locks >> us out of Jython support, at least for the time being. That’s another

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

> On 7 Jun 2017, at 20:06, Jim Baker wrote: > > Sorry, I wish this were true, but PyOpenSSL is not available on Jython, > because we do not yet support CFFI for Jython. CFFI support is something we > have looked at, but we have not implemented. (There is a related and

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

On Wed, Jun 7, 2017 at 2:31 AM, Cory Benfield wrote: > > On 6 Jun 2017, at 18:49, Jim Baker 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 >

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

On Jun 7, 2017 6:29 AM, "Victor Stinner" wrote: 2017-06-07 10:56 GMT+02:00 Nathaniel Smith : > Another testing challenge is that the stdlib ssl module has no way to > trigger a renegotiation, and therefore there's no way to write tests > to check that it

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

> On 7 Jun 2017, at 14:29, Victor Stinner wrote: > > 2017-06-07 10:56 GMT+02:00 Nathaniel Smith : >> Another testing challenge is that the stdlib ssl module has no way to >> trigger a renegotiation, and therefore there's no way to write tests >> to

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

2017-06-07 10:56 GMT+02:00 Nathaniel Smith : > Another testing challenge is that the stdlib ssl module has no way to > trigger a renegotiation, and therefore there's no way to write tests > to check that it properly handles a renegotiation, even though > renegotiation is by far the

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

On Tue, Jun 6, 2017 at 10:49 AM, Jim Baker 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

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

> On 6 Jun 2017, at 18:49, Jim Baker 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

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

On 6 June 2017 at 20:08, Nathaniel Smith wrote: > On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan wrote: >> The reason this kind of approach is really attractive to >> redistributors from a customer risk management perspective is that >> like gevent's

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

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

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

On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan 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

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

On 6 June 2017 at 10:59, Nathaniel Smith wrote: > On Jun 5, 2017 7:01 AM, "Nick Coghlan" wrote: > > On 5 June 2017 at 21:44, Donald Stufft wrote: >> Is pip allowed to use the hypothetical _ensurepip_ssl outside of >> ensurepip? > > Yes, so

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

On Jun 5, 2017 7:01 AM, "Nick Coghlan" wrote: On 5 June 2017 at 21:44, Donald Stufft wrote: > Is pip allowed to use the hypothetical _ensurepip_ssl outside of ensurepip? Yes, so something like _tls_bootstrap would probably be a better name for the helper

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

On 5 June 2017 at 21:44, Donald Stufft wrote: > Is pip allowed to use the hypothetical _ensurepip_ssl outside of ensurepip? Yes, so something like _tls_bootstrap would probably be a better name for the helper module (assuming we go down the "private API to bootstrap 3rd party

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

> On Jun 5, 2017, at 7:00 AM, Nick Coghlan wrote: > > On 5 June 2017 at 18:42, Cory Benfield > wrote: >> On 3 Jun 2017, at 07:25, Nick Coghlan wrote: >> As a result, as awkward and annoying as it would be,

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

> On 5 Jun 2017, at 12:00, Nick Coghlan wrote: > > Would you be OK with the notion of a "just for pip bootstrapping" > private backend in _ensurepip_ssl? > > That is, the only officially supported async-backed requests > configuration on Py2 would be with the PyOpenSSL

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

On 5 June 2017 at 18:42, Cory Benfield wrote: > On 3 Jun 2017, at 07:25, Nick Coghlan wrote: > As a result, as awkward and annoying as it would be, I'm wondering if > the structure of the requests migration may need to be something like: > > - switch

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

> On 3 Jun 2017, at 07:25, Nick Coghlan wrote: > > As a result, as awkward and annoying as it would be, I'm wondering if > the structure of the requests migration may need to be something like: > > - switch unconditionally to an async backend on Py3 > - switch conditionally

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

> On 2 Jun 2017, at 17:59, Donald Stufft wrote: > > I suspect (though I’d let him speak for himself) that Cory would rather > continue to be sync only than require pip to go back to not using requests. We are not wedded to supporting pip, but I think the interaction between

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

> On 2 Jun 2017, at 17:39, Nick Coghlan wrote: > > On 3 June 2017 at 02:22, Donald Stufft wrote: >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because having pip import >>

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

On 3 June 2017 at 08:21, Nathaniel Smith wrote: > On Fri, Jun 2, 2017 at 1:29 PM, Terry Reedy wrote: >> On 6/2/2017 12:21 PM, Barry Warsaw wrote: >>> >>> On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote: >> >> The benefit of making any backport a private

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

On Fri, Jun 2, 2017 at 1:29 PM, Terry Reedy wrote: > On 6/2/2017 12:21 PM, Barry Warsaw wrote: >> >> On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote: > > >>> The benefit of making any backport a private API is that it would mean >>> we weren't committing to support that API for

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

On 6/2/2017 12:21 PM, Barry Warsaw wrote: On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote: The benefit of making any backport a private API is that it would mean we weren't committing to support that API for general use: it would be supported *solely* for the use case discussed in the PEP

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

On Jun 2, 2017 7:24 AM, "Ben Darnell" wrote: The PEP's rationale is now "This PEP will help facilitate the future adoption of :pep:`543` across all supported Python versions, which will improve security for both Python 2 and Python 3 users." What exactly are these security

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

> On Jun 2, 2017, at 12:41 PM, Antoine Pitrou wrote: > > On Fri, 2 Jun 2017 12:22:06 -0400 > Donald Stufft wrote: >> >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because

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

On Sat, Jun 03, 2017 at 02:10:50AM +1000, Nick Coghlan wrote: > * and figure out some other pip-specific option for ensurepip > bootstrapping (like a *private* MemoryBIO implementation, or falling > back to synchronous mode in requests) Ignoring Ben's assertion regarding the legitimacy of async

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

> On Jun 2, 2017, at 12:39 PM, Nick Coghlan wrote: > > On 3 June 2017 at 02:22, Donald Stufft wrote: >> It’s not just bootstrapping that pip has a problem with for C extensions, it >> also prevents upgrading PyOpenSSL on Windows because having pip import

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

On Fri, 2 Jun 2017 12:22:06 -0400 Donald Stufft wrote: > > It’s not just bootstrapping that pip has a problem with for C extensions, it > also prevents upgrading PyOpenSSL on Windows because having pip import > PyOpenSSL locks the .dll, and we can’t delete it or overwrite it

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

On 3 June 2017 at 02:22, Donald Stufft wrote: > It’s not just bootstrapping that pip has a problem with for C extensions, it > also prevents upgrading PyOpenSSL on Windows because having pip import > PyOpenSSL locks the .dll, and we can’t delete it or overwrite it until the >

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

> On Jun 2, 2017, at 12:10 PM, Nick Coghlan wrote: > > On 2 June 2017 at 19:42, Victor Stinner wrote: >> Thanks Cory for the long explanation. Let me try to summarize (tell me >> if I'm wrong). >> >> We have 3 options: >> >> * Do nothing: reject

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

On Jun 03, 2017, at 02:10 AM, Nick Coghlan wrote: >* Introduce a dependency from requests onto PyOpenSSL when running in >async mode on Python 2.7 in the general case, and figure out some >other pip-specific option for ensurepip bootstrapping (like a >*private* MemoryBIO implementation, or

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

On 2 June 2017 at 19:42, Victor Stinner wrote: > Thanks Cory for the long explanation. Let me try to summarize (tell me > if I'm wrong). > > We have 3 options: > > * Do nothing: reject the PEP 546 and let each project handles security > on its own (current status co) > *

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

The PEP's rationale is now "This PEP will help facilitate the future adoption of :pep:`543` across all supported Python versions, which will improve security for both Python 2 and Python 3 users." What exactly are these security improvements? My understanding (which may well be incorrect) is that

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

Thanks you for all the explanations. So to summarize my opinion, I'm still -0.5 on this PEP. I would also like to see the issues Jython, Ubuntu et al. have mentioned solved before this is accepted. Regards Antoine. On Fri, 2 Jun 2017 11:42:58 +0200 Victor Stinner

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

> On 2 Jun 2017, at 10:42, Victor Stinner wrote: > > Writing new code seems more risky and error-prone than backporting > already "battle-tested" MemoryBIO from master. I also expect that > writing code to validate certificate will be longer than the "100 > lines of C

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

Thanks Cory for the long explanation. Let me try to summarize (tell me if I'm wrong). We have 3 options: * Do nothing: reject the PEP 546 and let each project handles security on its own (current status co) * Write *new* C code, maybe using certitude as a starting point, to offload certifcate

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

> On 1 Jun 2017, at 20:59, Steve Dower wrote: > > On 01Jun2017 1010, Nathaniel Smith wrote: >> I believe that for answering this question about the ssl module, it's really >> only Linux users that matter, since pip/requests/everyone else pushing for >> this only want

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

On 01Jun2017 1010, Nathaniel Smith wrote: I believe that for answering this question about the ssl module, it's really only Linux users that matter, since pip/requests/everyone else pushing for this only want to use ssl.MemoryBIO on Linux. Their plan on Windows/MacOS (IIUC) is to stop using

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

> On Jun 1, 2017, at 3:57 PM, Donald Stufft wrote: > > Note that on macOS, within the next year macOS users using the system Python > are going to be unable to talk to PyPI anyways (unless Apple does something > here, which I think they will), but in either case, Apple was

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

> On Jun 1, 2017, at 3:51 PM, Paul Moore wrote: > > Linux users often use the OS-supplied Python, and so getting the > distributions to upgrade, and to backport upgrades to old versions of > their OS and (push those backports as required updates) is the route > to get the

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

> On Jun 1, 2017, at 1:09 PM, Barry Warsaw wrote: > > On Jun 02, 2017, at 02:14 AM, Chris Angelico wrote: > >> But it also includes people on stable Linux distros, where they have >> automatic updates provided by Red Hat or Debian or whomever, so a change like >> this WILL

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

On Thu, Jun 01, 2017 at 04:01:54PM +0100, Cory Benfield wrote: > > lower net cost than getting the world into a situation where pip no > > longer runs on the >1e6 EC2 instances that will be running Ubuntu > > 14.04/16.04 LTS until the turn of the next decade. > So for the record I’m assuming

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

On 1 June 2017 at 17:14, Chris Angelico wrote: > Python 2 users include people on Windows who install it themselves, > and then have no mechanism for automatic updates. They'll probably > stay on whatever 2.7.x they first got, until something forces them to > update. But it also

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

On Jun 01, 2017, at 07:22 PM, Victor Stinner wrote: >I can help Canonical to backport MemoryBIO *if they want* to >cherry-pick this feature ;-) (Pedantically speaking, this falls under the Ubuntu project's responsibility, not directly Canonical.) Writing the patch is only part of the process:

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

2017-06-01 19:10 GMT+02:00 Nathaniel Smith : > (...) since pip/requests/everyone else pushing for > this only want to use ssl.MemoryBIO on Linux. Their plan on Windows/MacOS > (IIUC) is to stop using the ssl module entirely in favor of new ctypes > bindings for their respective

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

2017-06-01 19:09 GMT+02:00 Barry Warsaw : > By 2020, only Ubuntu 16.04 and 18.04 will still be maintained, so while 18.04 > will likely contain whatever the latest 2.7 is available at that time, 16.04 > won't track upstream point releases, but instead will get select cherry >

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

On Jun 1, 2017 9:20 AM, "Chris Angelico" wrote: On Fri, Jun 2, 2017 at 1:01 AM, Cory Benfield wrote: > The answer to that is honestly not clear to me. I chatted with the pip developers, and they have 90%+ of their users currently on Python 2, but more than

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

On Jun 02, 2017, at 02:14 AM, Chris Angelico wrote: >But it also includes people on stable Linux distros, where they have >automatic updates provided by Red Hat or Debian or whomever, so a change like >this WILL propagate - particularly (a) as the window is three entire years, >and (b) if the

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

2017-06-01 18:51 GMT+02:00 Chris Angelico : > Hmm. So it's really hard to know. Pity. I suppose it's too much to ask > for IP-based stat exclusion for the most commonly-used CI systems > (Travis, Circle, etc)? Still, it does look like most pip usage happens > on Linux. Also, it

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

On Fri, Jun 2, 2017 at 2:35 AM, Cory Benfield wrote: > I have figures for the download numbers, which are an awkward proxy because > most people don’t CI on Windows and macOS, but they’re the best we have. > Linux has approximately 20x the download numbers of either Windows

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

> On 1 Jun 2017, at 17:14, Chris Angelico wrote: > > > Do you have figures for how many people use pip on Windows vs Linux vs Mac OS? I have figures for the download numbers, which are an awkward proxy because most people don’t CI on Windows and macOS, but they’re the best

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

On Fri, Jun 2, 2017 at 1:01 AM, Cory Benfield wrote: > The answer to that is honestly not clear to me. I chatted with the pip > developers, and they have 90%+ of their users currently on Python 2, but more > than half of those are on 2.7.9 or later. This shows some interest

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

On Thu, 1 Jun 2017 15:09:41 +0100 Cory Benfield wrote: > > As to the plans to move Requests to a more event loop-y model, I think that > it does stand in the way of this, but only insomuch as, again, we want our > event loopy model to be as bug-free as possible. But I can

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

> On 1 Jun 2017, at 15:10, David Wilson wrote: > Finding someone to audit the signature checking capabilities of [0] will > have vastly lower net cost than getting the world into a situation where > pip no longer runs on the >1e6 EC2 instances that will be running Ubuntu

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

Trying to transfer github comments from https://github.com/python/peps/pull/272#pullrequestreview-41388700: I said: > Tornado has been doing TLS in an event-loop model in python 2.5+ with just wrap_socket, no MemoryBIO necessary. What am I missing? MemoryBIO certainly gives some extra

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

On Thu, Jun 01, 2017 at 12:18:48PM +0100, Cory Benfield wrote: > So, this will work, but at a performance and code cleanliness cost. > This essentially becomes a Python-2-only code-path, and a very large > and complex one at that. "Doctor, it hurts when I do this .." Fine, then how about rather

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

> On 1 Jun 2017, at 14:53, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 14:37:55 +0100 > Cory Benfield wrote: >>> >>> And indeed it doesn't. Unless the target user base for pip is widely >>> different than Python's, it shouldn't cause you any problems

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

On Thu, 1 Jun 2017 14:37:55 +0100 Cory Benfield wrote: > > > > And indeed it doesn't. Unless the target user base for pip is widely > > different than Python's, it shouldn't cause you any problems either. > > Maybe not now, but I think it’s fair to say that it did, right?

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

> On 1 Jun 2017, at 14:21, Antoine Pitrou wrote: > > > Le 01/06/2017 à 15:12, Cory Benfield a écrit : >> >> I don’t know what to do with that answer, really. I gave you some data (80%+ >> of requests downloads over the last month were Python 2), and you responded >> with

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

Le 01/06/2017 à 15:12, Cory Benfield a écrit : > > I don’t know what to do with that answer, really. I gave you some data (80%+ > of requests downloads over the last month were Python 2), and you responded > with “it doesn’t cause us problems”. And indeed it doesn't. Unless the target user

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

> On 1 Jun 2017, at 12:20, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 12:01:41 +0100 > Cory Benfield wrote: >> In principle, sure. In practice, that means most of our users don’t use >> those features and so we don’t get any feedback on whether

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

On Thu, 1 Jun 2017 12:01:41 +0100 Cory Benfield wrote: > In principle, sure. In practice, that means most of our users don’t use those > features and so we don’t get any feedback on whether they’re good solutions > to the problem. On bugs.python.org we get plenty of feedback

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

> On 1 Jun 2017, at 12:09, David Wilson wrote: > > On Thu, Jun 01, 2017 at 11:47:31AM +0100, Cory Benfield wrote: > >> I have, but discarded the idea. > > I'm glad to hear it was given sufficent thought. :) > > I have one final 'crazy' idea, and actually it does not

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

On Thu, Jun 01, 2017 at 11:47:31AM +0100, Cory Benfield wrote: > I have, but discarded the idea. I'm glad to hear it was given sufficent thought. :) I have one final 'crazy' idea, and actually it does not seem to bad at all: can't you just fork a subprocess or spawn threads to handle the

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

> On 1 Jun 2017, at 11:51, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 11:45:14 +0100 > Cory Benfield wrote: >> >> I am claiming that using OpenSSL certificate validation with root stores >> that are not intended for OpenSSL can be. This is because

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

> On 1 Jun 2017, at 11:39, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 11:22:21 +0100 > Cory Benfield wrote: >> >> Who is the “we” that should move on? Python core dev? Or the Python >> ecosystem? > > Sorry. Python core dev certainly. As for the

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

On Thu, 1 Jun 2017 11:45:14 +0100 Cory Benfield wrote: > > I am claiming that using OpenSSL certificate validation with root stores that > are not intended for OpenSSL can be. This is because trust of a certificate > is non-binary. For example, consider WoSign. The Windows

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

> On 1 Jun 2017, at 11:39, David Wilson wrote: > > Hi Cory, > > On Thu, Jun 01, 2017 at 11:22:21AM +0100, Cory Benfield wrote: > >> We want to support as many TLS backends as possible. > > Just a wild idea, but have you investigated a pure-Python fallback for > 2.7

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

> On 1 Jun 2017, at 11:28, Antoine Pitrou wrote: > > > Le 01/06/2017 à 12:23, Cory Benfield a écrit : >> >> No it can’t. >> >> OpenSSL builds chains differently, and disregards some metadata that Windows >> and macOS store, which means that cert validation will work

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

On Thu, 1 Jun 2017 11:22:21 +0100 Cory Benfield wrote: > > Who is the “we” that should move on? Python core dev? Or the Python ecosystem? Sorry. Python core dev certainly. As for the rest of the ecosystem, it is moving on as well. > Requests is stuck in a place from which

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

Hi Cory, On Thu, Jun 01, 2017 at 11:22:21AM +0100, Cory Benfield wrote: > We want to support as many TLS backends as possible. Just a wild idea, but have you investigated a pure-Python fallback for 2.7 such as TLSlite? Of course the fallback need only be used during bootstrapping, and the

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

> On 1 Jun 2017, at 11:18, Antoine Pitrou wrote: > > On Thu, 1 Jun 2017 20:05:48 +1000 > Chris Angelico wrote: >> >> As stated in this thread, OS-provided certificates are not handled by >> that. For instance, if a local administrator distributes a

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

Le 01/06/2017 à 12:23, Cory Benfield a écrit : > > No it can’t. > > OpenSSL builds chains differently, and disregards some metadata that Windows > and macOS store, which means that cert validation will work differently than > in the system store. This can lead to pip accepting a cert marked

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

> On 1 Jun 2017, at 10:23, Antoine Pitrou wrote: > > Yes, I disagree. We needn't backport that new API to Python 2.7. > Perhaps it's time to be reasonable: Python 2.7 has been in bugfix-only > mode for a very long time. Python 3.6 is out. We should move on. Who is the

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

On Thu, 1 Jun 2017 20:05:48 +1000 Chris Angelico wrote: > > As stated in this thread, OS-provided certificates are not handled by > that. For instance, if a local administrator distributes a self-signed > cert for the intranet server, web browsers will use it, but pip will >

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

On Thu, Jun 1, 2017 at 8:01 PM, Antoine Pitrou wrote: > On Thu, 1 Jun 2017 19:50:22 +1000 > Chris Angelico wrote: >> On Thu, Jun 1, 2017 at 7:23 PM, Antoine Pitrou wrote: >> >> Do you also disagree on the need of the need of the PEP 546

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

On Thu, 1 Jun 2017 19:50:22 +1000 Chris Angelico wrote: > On Thu, Jun 1, 2017 at 7:23 PM, Antoine Pitrou wrote: > >> Do you also disagree on the need of the need of the PEP 546 > >> (backport) to make the PEP 543 (new TLS API) feasible in practice? > > > >

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

On Thu, Jun 1, 2017 at 7:23 PM, Antoine Pitrou wrote: >> Do you also disagree on the need of the need of the PEP 546 >> (backport) to make the PEP 543 (new TLS API) feasible in practice? > > Yes, I disagree. We needn't backport that new API to Python 2.7. > Perhaps it's time

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

Le 01/06/2017 à 11:13, Victor Stinner a écrit : > That's why pip uses Requests which uses certifi (Mozilla > bundled root certificate authorities.) pip could use certifi without using Requests. My guess is that Requests is used mostly because it eases coding. > pip and so Requests are part of

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

2017-06-01 10:57 GMT+02:00 Antoine Pitrou : > If Requests is to remain 2.7-compatible, it's up to Requests to do the > necessary work to do so. In practice, CPython does include Requests in ensurepip. Because of that, it means that Requests cannot use any C extension. CPython

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

On Wed, 31 May 2017 14:09:20 -0600 Jim Baker wrote: > > But I object to a completely new feature being added to 2.7 to support the > implementation of event loop SSL usage. This feature cannot be construed as > a security fix, and therefore does not qualify as a feature

  1   2   >