[Python-Dev] Proposed schedule for 3.4.2 (original) (raw)

Guido van Rossum guido at python.org
Tue Sep 9 05:32:24 CEST 2014

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 monkeypatch feels unnecessarily mean -- I see no reason why the code can't be in the standard library. It's a bit like the emergency hammer on a train -- what keeps riders from misusing it is convention (and the sign next to it), since locking it up would miss the point.

Do note that there are a couple of different common patterns for how this is used in legacy code, e.g. urllib vs.urllib2, URLOpener vs FancyURLOpener, urlopen vs. urlretrieve; there are also some internal calls, e.g. in response to redirects. The ultimate form of the solution (keyword argument of alternate function or whatever) may depend on the needs of these various (ancient) architectures.

Regarding 3.4 and 3.5, there's presumably much less legacy code for 3.4, but its expected lifetime is also much shorter than 2.7's (since we're already close to releasing 3.5). So I'm still a bit torn -- in the end one reason to do it in 3.4 is that 3.4 shouldn't have a weaker default than 2.7.

Onwards,

On Mon, Sep 8, 2014 at 7:46 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:

Well, this thread seems to be top-posted.... so...

Why not provide urlopenwithscarykeywordparameter 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 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 many urlopen("https"//") calls, well, they probably don't mind the busywork of editing each and every one of them. I'm fine with giving the actual keyword parameter a scary-sounding ugly name. On Mon, Sep 8, 2014 at 3:48 PM, Donald Stufft <donald at stufft.io> wrote:

On Sep 8, 2014, at 6:43 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 9 Sep 2014 08:30, "Donald Stufft" <donald at 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 more obviously dangerous name is much simpler than explaining to people "Here, copy this chunk of code you don't understand". If we were starting with a blank slate there's no way we'd offer such a thing, but as Jim pointed out, we do want to make it relatively easy for Standard Operating Environment maintainers to hack around it if necessary. Cheers, Nick. > > import ssl > import urllib.request > realurlopen = urllib.request.urlopen > def unverified(*args, **kwargs): > if not kwargs.keys() & {“context”, “cafile”, “capath”, “cadefault”}: > ctx = ssl.createdefaultcontext() > ctx.verifymode = CERTNONE > ctx.verifyhostname = False > kwargs[“context”] = ctx > return realurlopen(*args, **kwargs) > > --- > Donald Stufft > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > Why isn’t documentation with appropriate red warnings a suitable place if we really must have it? That sounds like a much better solution that some weird function people monkeypatch. It gives them more control over things (maybe they have a valid certificate chain, but an invalid host name!), it’ll work across all Python implementations, and most importantly, it gives us a place where there is some long form location to be like “yea you really probably don’t want to be doing this” in big red letters. Overall I’m -1 on either offering the function or documenting it at all, but if we must do something then I think documentation is more than enough.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140908/41a15f0a/attachment.html>

More information about the Python-Dev mailing list