On 11 May 2015 at 20:23, Donald Stufft <donald at stufft.io> wrote: > On May 11, 2015, at 6:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: >> We made the decision when PEP 476 was accepted that this change turned >> a silent security failure into a noisy one, rather than being a >> regression in its own right. PEP 493 isn't about disagreeing with that >> decision, it's about providing a smoother upgrade path in contexts >> where letting the security failure remain silent is deemed to be >> preferred in the near term. > > I don't really agree that the decision to disable TLS is an environment one, > it's really a per application decision. This is why I was against having some > sort of global off switch for all of Python because just because one > application needs it turned off doesn't mean you want it turned off for another > Python application. The scenario I'm interested in is the one where it *was* off globally (i.e. you were already running Python 2.7.8 or earlier) and you want to manage a global rollout of a new Python version that supports being configured to verify HTTPS certificates by default, while making the decision on whether or not to enable HTTPS certificate verification on a server-by-server basis, rather than having that decision be coupled directly to the rollout of the updated version of Python. I agree that the desired end state is where Python 3 is, and where upstream Python 2.7.9+ is, this is solely about how to facilitate folks getting from point A to point B without an intervening window of "I broke the world and now my boss is yelling at me about it" :) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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