On Mon, 3 Jun 2013 17:47:31 -0400 Donald Stufft <donald@stufft.io> wrote:
On Jun 3, 2013, at 5:41 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 3 Jun 2013 22:31:40 +0100 Paul Moore <p.f.moore@gmail.com> wrote:
Some legit sites with proper certificates still manage to muck something up administratively (developer.quicksales.com.au has a cert from RapidSSL but doesn't bundle the intermediates, and I've told their devs about it, but all I can do is disable cert checking). This will break code in ways that will surprise people greatly. But I'd still rather the default be True.
I'm happy if the "will cease to work" clause only says "some sites with broken security configurations may stop working" with a clear explanation that it is *their* fault, not Python's. I'd also expect that the same sites would fail in browsers - if not, we should also be able to make them work (or face cries of "well, Internet Explorer/Firefox doesn't have a problem with my site, why does Python?").
Keep in mind that not every HTTPS service is a Web site that is meant to be readable with a browser. Some are Web services, possibly internal, possibly without a domain name (and, therefore, probably a non-matching certificate subject name).
They should need to explicitly opt in to disabling the checks that allow that to work.
Obviously, which means compatibility is broken with existing code. Regards Antoine.