On 01.09.2014 10:09, Nick Coghlan wrote:
On 1 September 2014 17:13, Christian Heimes christ...@python.org 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
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
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
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,
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 solipsis at pitrou.net wrote:
RFC 2818 (HTTP over TLS) has
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 8 September 2014 18:23, Jim J. Jewett jimjjew...@gmail.com 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
On Wed, Sep 3, 2014 at 2:52 PM, Victor Stinner victor.stin...@gmail.com
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
On Wed, Sep 3, 2014 at 3:48 PM, Stephen J. Turnbull step...@xemacs.org
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
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 03:25, Jim J. Jewett jimjjew...@gmail.com 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
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
On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield c...@lukasa.co.uk wrote:
On 8 September 2014 18:23, Jim J. Jewett jimjjew...@gmail.com 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
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
On 9 Sep 2014 10:48, Jim J. Jewett jimjjew...@gmail.com 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
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
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
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
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 gu...@python.org wrote:
The multiple threads going on are confusing (or maybe GMail makes them more
confusing), but the architecture you
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
30 matches
Mail list logo
