Re: [Python-Dev] Proposed schedule for 3.4.2

On 9/8/2014 8:41 PM, Stephen J. Turnbull wrote: > Why not provide _urlopen_with_scary_keyword_parameter as the > monkey-patch option? > > So after the (global to the module) monkeypatch, they would_still_ have > to add the keyword parameter. I understand the hardline position, though

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

It’s create_default_context() -> https://docs.python.org/3.4/library/ssl.html#ssl.create_default_context > On Sep 8, 2014, at 11:40 PM, Guido van Rossum wrote: > > The multiple threads going on are confusing (or maybe GMail makes them more > confusing), but the architecture you are sketching

Re: [Python-Dev] Proposed schedule for 3.4.2

Glenn Linderman writes: > Well, this thread seems to be top-posted so... Not a good enough reason for me! > Why not provide _urlopen_with_scary_keyword_parameter as the > monkey-patch option? > > So after the (global to the module) monkeypatch, they would _still_ have > to add the k

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

The multiple threads going on are confusing (or maybe GMail makes them more confusing), but the architecture you are sketching here sounds good. I can't find get_default_context() in the repo, but perhaps I need to refresh, or perhaps you're talking about a design in a PEP. On Mon, Sep 8, 2014 at

Re: [Python-Dev] Proposed schedule for 3.4.2

Replacing urllib.urlopen(url) with urllib._unsafe_urlopen_without_secure_https(url) would be fine too (actual name to be picked by whoever writes the code) but I don't see that it offers much more of a barrier against abuse of this compatibility feature compared to a keyword argument. Requiring a

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 9 Sep 2014 10:48, "Jim J. Jewett" wrote: > I assume that adding _unverified_urlopen or urlopen(context=...) do > provide incremental improvements compatible with the eventual full > opt-in. If so, adding them is probably reasonable, but I think the > PEP should explicitly list all such approve

Re: [Python-Dev] Proposed schedule for 3.4.2

Well, this thread seems to be top-posted so... Why not provide _urlopen_with_scary_keyword_parameter as the monkey-patch option? So after the (global to the module) monkeypatch, they would _still_ have to add the keyword parameter. On 9/8/2014 4:31 PM, Guido van Rossum wrote: I still p

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield wrote: > On 8 September 2014 18:23, Jim J. Jewett wrote: >> Summary: There needs to be a simple way to opt out at install time. >> It would be far better to offer more fine-grained control, but leaving >> that better solution to downstream is accepta

Re: [Python-Dev] Proposed schedule for 3.4.2

I still prefer having a parameter on urlopen (or thereabouts) -- it feels wrong to make it easier to change this globally than on a per-call basis, and if you don't understand monkey-patching, it's impossible to debug if you put the patch in the wrong place. For the poor soul who has a script with

Re: [Python-Dev] Proposed schedule for 3.4.2

> On Sep 8, 2014, at 6:43 PM, Nick Coghlan wrote: > > > On 9 Sep 2014 08:30, "Donald Stufft" > wrote: > > > > If someone wants to do this, can’t they write their own 6 line function? > > Unfortunately not, as the domain knowledge required to know what those six > lin

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 08:30, "Donald Stufft" wrote: > > If someone wants to do this, can’t they write their own 6 line function? Unfortunately not, as the domain knowledge required to know what those six lines should look like is significant. Keeping the old unsafe behaviour around with a more obviously

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 9 Sep 2014 03:25, "Jim J. Jewett" wrote: > Examples of good enough: > "Add this file to site-packages" > "Add this environment variable with this setting" > "Add this command line switch to your launch script" The monkeypatching hack I proposed would work correctly in sitecustomize

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 08:20, "Nick Coghlan" wrote: > > > On 9 Sep 2014 04:00, "Barry Warsaw" wrote: > > > > > >This would need to be updated first, once it *did* take such an argument, > > >this would be accomplished by: > > > > > >context = ssl.create_default_context() > > >context.verify_mode = CERT_OP

Re: [Python-Dev] Proposed schedule for 3.4.2

> On Sep 8, 2014, at 6:20 PM, Nick Coghlan wrote: > > > On 9 Sep 2014 04:00, "Barry Warsaw" > wrote: > > > > > >This would need to be updated first, once it *did* take such an argument, > > >this would be accomplished by: > > > > > >context = ssl.create_default_context

Re: [Python-Dev] Proposed schedule for 3.4.2

On Sep 09, 2014, at 08:20 AM, Nick Coghlan wrote: >We could actually make it an "official" hack: > >import urllib.request >urllib.request.urlopen = urllib.request._unverified_urlopen > >Or else the user can just change the code to call the unverified one >directly. > >All we'd have to do i

Re: [Python-Dev] Proposed schedule for 3.4.2

On 9 Sep 2014 04:00, "Barry Warsaw" wrote: > > > >This would need to be updated first, once it *did* take such an argument, > >this would be accomplished by: > > > >context = ssl.create_default_context() > >context.verify_mode = CERT_OPTIONACERT_NONE > >context.verify_hostname = False > >urllib.re

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Wed, Sep 3, 2014 at 3:48 PM, Stephen J. Turnbull wrote: > Guido van Rossum writes: > > > lot: five years ago (when I worked at Google!) it was common to find > > internal services that required SSL but had a misconfigured certificate, > > and the only way to access those services was to ove

Re: [Python-Dev] Sad status of Python 3.x buildbots

On Wed, Sep 3, 2014 at 2:52 PM, Victor Stinner wrote: > > > ARMv7 3.x: "Read-only file system", Mercurial fails... > > I sent an email to Gregory P. Smith (owner). > For mine, its a case of me not having any monitoring for it. Sending me an email worked. In this case the SSD (a very fast usb3 m

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On 8 September 2014 18:23, Jim J. Jewett wrote: > Summary: There needs to be a simple way to opt out at install time. > It would be far better to offer more fine-grained control, but leaving > that better solution to downstream is acceptable. Does this argument apply to a hypothetical 2.7 backpo

Re: [Python-Dev] Proposed schedule for 3.4.2

+1 for the suggested change to 2.7. Something I have put off in the work on SSL support in Jython 2.7 is what to do about the possibility of adding a large security hole to support standard Python behavior here with CERT_NONE. By default, we use the standard trust database and corresponding manage

Re: [Python-Dev] Proposed schedule for 3.4.2

On Sep 08, 2014, at 10:44 AM, Alex Gaynor wrote: >*Shifts uncomfortably* it looks like presently there's not a good way to >change anything about the SSL configuration for urllib.request.urlopen. It >does not take a `context` argument, as the http.client API does: >https://docs.python.org/3/librar

Re: [Python-Dev] Proposed schedule for 3.4.2

Well, get cracking then! :-) On Mon, Sep 8, 2014 at 10:44 AM, Alex Gaynor wrote: > *Shifts uncomfortably* it looks like presently there's not a good way to > change anything about the SSL configuration for urllib.request.urlopen. It > does not take a `context` argument, as the http.client API do

Re: [Python-Dev] Proposed schedule for 3.4.2

*Shifts uncomfortably* it looks like presently there's not a good way to change anything about the SSL configuration for urllib.request.urlopen. It does not take a `context` argument, as the http.client API does: https://docs.python.org/3/library/urllib.request.html#module-urllib.request and instea

Re: [Python-Dev] Proposed schedule for 3.4.2

I will pronounce for 3.4 once you point me to the documentation that explains how to disable cert validation for an example program that currently pulls down an https URL using urlopen. Without adding package dependencies. On Mon, Sep 8, 2014 at 10:25 AM, Alex Gaynor wrote: > Guido van Rossum p

Re: [Python-Dev] Proposed schedule for 3.4.2

Guido van Rossum python.org> writes: > > Would you be willing to officially pronounce on PEP-476 in the context of 3.4.x, so we can get it into the release, and then we can defer on officially approving it for 2.7.X until we figure out all the moving pieces? Cheers, Alex

[Python-Dev] Backwards compatibility after certificate autovalidation

Summary: There needs to be a simple way to opt out at install time. It would be far better to offer more fine-grained control, but leaving that better solution to downstream is acceptable. On 3 September 2014 01:19, Antoine Pitrou wrote: > RFC 2818 (HTTP over TLS) has the following language

Re: [Python-Dev] Proposed schedule for 3.4.2

On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan wrote: > > It would also be good to get Guido's official verdict on PEP 476 (the > switch to validating HTTPS by default) in time for 3.4.2. Based on the > previous discussion, Alex updated the PEP to suggest "just fix it" for > all of 3.5, 3.4.x and 2

Re: [Python-Dev] cpython and parallel make

Hi, Open an issue on bugs.python.org and attach the patch there (it should also > ask you so sign the contributor agreement, but if not then please also sign > that). > Submitted as http://bugs.python.org/issue22359 , and signed the agreement. Cheers, Jonas _

Re: [Python-Dev] Proposed schedule for 3.4.2

On 8 September 2014 14:28, Ned Deily wrote: > In article <540c521c.7070...@hastings.org>, > Larry Hastings wrote: >> Matthias asked me when I was going to release 3.4.2. I propose the >> following schedule: >> >> Tag 3.4.2rc1 Friday Sep 12 2014 >> Release 3.4.2rc1 Saturday Sep 13 2014 >

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On 01.09.2014 10:09, Nick Coghlan wrote: > On 1 September 2014 17:13, Christian Heimes wrote: >> On 01.09.2014 08:44, Nick Coghlan wrote: >>> Yes, it would have exactly the same security failure modes as >>> sitecustomize, except it would only fire if the application >>> imported the ssl module. >