On Tue, 2 Sep 2014 22:16:18 +0000 (UTC) Alex Gaynor email@example.com wrote:
Furthermore, "disable verification" is a nonsensical thing to do with TLS.
It's not. For example, if you have an expired cert, all you can do AFAIK is to disable verification.
It really is a nonsensical operation, accepting any random TLS certificate without pinning or use of a certificate authorities makes a valid connection completely indistinguishable from a MITM attack.
It's still distinguishable from a passively-eavesdroppable clear-text connection, though.
This whole scenario seems to be predicated on a siutation where: You have a peer whose certificate you can't change, and you have a piece of code you can't change, and you're going to upgrade your Python installation, and you want to talk to this peer, and you need to use an encrypted channel, but don't really care if it's being MITM'd. It doesn't seem to me that this is reasonably Python's responsibility to deal with the fact that you have no ability to upgrade any of your infrastructure, except your Python version.
Oh, I agree that whoever upgrades their Python version should be able to fix any of their applications should they start failing. That's why I don't want to let new command-line options and environment variables proliferate in the name of damage control.