On Fri, 29 Aug 2014 18:00:50 -0400, Donald Stufft firstname.lastname@example.org wrote:
On Aug 29, 2014, at 5:42 PM, R. David Murray email@example.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!