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 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@stufft.io>           wrote:
                                      
                

                  
                                           
On Sep 8, 2014, at 6:43 PM, Nick Coghlan <ncoghlan@gmail.com>                         wrote:
                      
                      
                        
                          On 9 Sep 2014 08:30, "Donald Stufft" <donald@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
                          > _real_urlopen = urllib.request.urlopen
                          > def _unverified(*args, **kwargs):
                          >     if not kwargs.keys() &                           {“context”, “cafile”, “capath”, “cadefault”}:
                          >         ctx =                           ssl.create_default_context()
                          >         ctx.verify_mode = CERT_NONE
                          >         ctx.verify_hostname = False
                          >         kwargs[“context”] = ctx
                          >     return _real_urlopen(*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.
              
                                                 
  ">

(original) (raw)

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@g.nevcal.com> wrote:
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 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@stufft.io> wrote:

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


On 9 Sep 2014 08:30, "Donald Stufft" <donald@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
\> \_real\_urlopen = urllib.request.urlopen
\> def \_unverified(\*args, \*\*kwargs):
\> if not kwargs.keys() & {“context”, “cafile”, “capath”, “cadefault”}:
\> ctx = ssl.create\_default\_context()
\> ctx.verify\_mode = CERT\_NONE
\> ctx.verify\_hostname = False
\> kwargs\[“context”\] = ctx
\> return \_real\_urlopen(\*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@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)