On Tue, 02 Sep 2014 22:16:18 -0000, Alex Gaynor <alex.gay...@gmail.com> wrote: > 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.
I would say that is an excellent summary, except that you are sometimes *forced* to use an encrypted channel (the device only opens the https port). That is, in the real messy world of network devices, accepting an invalid cert is not a nonsensical operation. (Of course, what I really want is to be able to say "I know this cert has invalid fields, accept it anyway, but warn me if it changes when I connect again".) It's a good point that the actual number of people who will be hit by this and can't hack the code in question will be (possibly vanishingly) small, especially if you only consider python3. But we've already had one call for a backport :) --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
