On Fri, 29 Aug 2014 18:00:50 -0400, Donald Stufft <donald at stufft.io> wrote: > > On Aug 29, 2014, at 5:42 PM, R. David Murray <rdmurray at bitdance.com> wrote: > > Especially if you want an accelerated change, there must be a way to > > *easily* get back to the previous behavior, or we are going to catch a > > lot of flack. There may be only 7% of public certs that are problematic, > > but I'd be willing to bet you that there are more not-really-public ones > > that are critical to day to day operations *somewhere* :) > > > > wget and curl have 'ignore validation' as a command line flag for a reason. > > > > Right, that’s why I’m on the fence :) > > On one hand, it’s going to break things for some people, (arguably they are > already broken, just silently so, but we’ll leave that argument aside) and a > way to get back the old behavior is good. There are already ways within > the Python code itself, so that’s covered. From outside of the Python code > there are ways if the certificate is untrusted but otherwise valid which are > pretty easy to do. The major “gap†is when you have an actual invalid > certificate due to expiration or hostname or some other such thing. > > On the other hand Python is not wget/curl and the people who are most > likely to be the target for a “I can’t change the code but I need to get the > old behavior back†are people who are likely to not be invoking Python > itself but using something written in Python which happens to be using > Python. IOW they might be executing “foobar†not “python -m foobarâ€. Right, so an environment variable is better than a command line switch, for Python. > Like I said though, I’m personally fine either way so don’t take this as > being against that particular change! Ack. --David
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4