On Mon, 8 Sep 2014 10:44:51 -0700
Alex Gaynor alex.gay...@gmail.com 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:
On Tue, 9 Sep 2014 08:20:52 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 9 Sep 2014 04:00, Barry Warsaw ba...@python.org 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()
On 09/08/2014 05:08 AM, Nick Coghlan wrote:
On 8 September 2014 14:28, Ned Deily n...@acm.org wrote:
As I've already discussed with Larry, I think adding a week to the
scheduled dates would be preferable. The original dates give pretty
short notice and there are a number of open issues that
On 8 September 2014 14:28, Ned Deily n...@acm.org wrote:
In article 540c521c.7070...@hastings.org,
Larry Hastings la...@hastings.org 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
On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan ncogh...@gmail.com 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,
Guido van Rossum guido at 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
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 alex.gay...@gmail.com 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/library/urllib.request.html#module-urllib.request
and
Well, get cracking then! :-)
On Mon, Sep 8, 2014 at 10:44 AM, Alex Gaynor alex.gay...@gmail.com 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
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:
+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
On 9 Sep 2014 04:00, Barry Warsaw ba...@python.org 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
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 is keep the
On Sep 8, 2014, at 6:20 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 9 Sep 2014 04:00, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
This would need to be updated first, once it *did* take such an argument,
this would be accomplished by:
context =
On 9 Sep 2014 08:20, Nick Coghlan ncogh...@gmail.com wrote:
On 9 Sep 2014 04:00, Barry Warsaw ba...@python.org 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
On 9 Sep 2014 08:30, Donald Stufft don...@stufft.io 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
On Sep 8, 2014, at 6:43 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 9 Sep 2014 08:30, Donald Stufft don...@stufft.io
mailto:don...@stufft.io 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
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
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
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
Glenn Linderman writes:
Well, this thread seems to be top-posted so...
Not a good enough reason for me!wink /
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
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 I
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
Tag 3.4.2 final Saturday Sep 27 2014
Release 3.4.2 final Sunday Sep 28 2014
Normally I want to tag on Saturdays and
In article 540c521c.7070...@hastings.org,
Larry Hastings la...@hastings.org 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
Tag 3.4.2 final Saturday Sep 27 2014
24 matches
Mail list logo
