On 24 November 2015 at 03:46, Nick Coghlan <ncoghlan@gmail.com> wrote:
I think there are three relevant categories here:
1. Folks who assume that "https" means the same thing in Python that it means in web browsers, and are currently experiencing a silent security failure 2. Folks who already know it doesn't, and are relying on that to keep their infrastructure working 3. Folks currently in group 2 who would like to improve their infrastructure to default to verifying certificates
I'm not directly interested in this PEP (any code I write that is relevant will run on Windows) but there's another group: 4. People who use https because it's the published API, but are only looking at internal systems (where the threat window is minimised) and the internal infrastructure is out of their control but insecure. Browser users and other apps have to go through pain to work (accepting self-signed certs, repeatedly responding "Yes" to security warnings). Python code written for internal use just works at the moment. Maybe it "shouldn't", in some abstract sense, but it *does* and that is important to users. This group may know that they are taking risks, and may want to improve the infrastructure, but they *can't*. And this change breaks their apps (possibly in ways they can't fix easily - not all client environments offer ways to add trust, there's a reason tools like wget have "ignore certificate checks" flags even though everyone knows they are a bad idea). The push for "secure by default" is important and needed, but needs to be handled in a more pragmatic way, recognising that Python is used in situations like the above, where people know they aren't doing the right thing, but have no better options. Shutting down their least bad option on a point of principle isn't helpful. Paul