On Fri, 29 Aug 2014 18:00:50 -0400, Donald Stufft <[email protected]> wrote: > > On Aug 29, 2014, at 5:42 PM, R. David Murray <[email protected]> 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
_______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
