<p dir="ltr"><br>
On 9 Sep 2014 08:20, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
><br>
> On 9 Sep 2014 04:00, "Barry Warsaw" <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> > ><br>
> > >This would need to be updated first, once it *did* take such an argument,<br>
> > >this would be accomplished by:<br>
> > ><br>
> > >context = ssl.create_default_context()<br>
> > >context.verify_mode = CERT_OPTIONACERT_NONE<br>
> > >context.verify_hostname = False<br>
> > >urllib.request.urlopen("<a href="https://something-i-apparently-dont-care-much-about">https://something-i-apparently-dont-care-much-about</a>",<br>
> > >context=context)<br>
> ><br>
> > There's probably an ugly hack possibility that uses unittest.mock.patch. ;)<br>
><br>
> We could actually make it an "official" hack:<br>
><br>
>     import urllib.request<br>
>     urllib.request.urlopen = urllib.request._unverified_urlopen</p>
<p dir="ltr">Thinking about it a bit more, I suspect httplib would be the right level for such a hack.</p>
<p dir="ltr">Either way, I actually think a monkeypatching based solution is a reasonable choice here. You can downgrade back to the old behaviour selectively (calling the unverified version or monkeypatching the calling module) or globally (monkeypatching the httplib module) </p>
<p dir="ltr">If folks go "Ewww, I'm going to fix my code or certs instead", that's a good outcome :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>