On Tue, 02 Sep 2014 20:59:54 -0400, Terry Reedy <tjre...@udel.edu> wrote: > On 9/2/2014 7:47 PM, Glyph Lefkowitz wrote: > > > > On Sep 2, 2014, at 4:28 PM, Nick Coghlan <ncogh...@gmail.com > > <mailto:ncogh...@gmail.com>> wrote: > > > >> On 3 Sep 2014 09:08, "David Reid" <dr...@dreid.org > >> <mailto:dr...@dreid.org>> wrote: > > >> > Clearly this change should be backported to Python2. > >> > >> Proposing to break backwards compatibility in a maintenance release (...) > > For code that depends on a bug, fixing the bug breaks compatibility > between releases without and with the fix. Nothing new. We > occasionally don't backpart disruptive bugfixes because of that. We also > backport some security fixes to otherwise unmaintained versions. > > > As we keep saying, this is not a break in backwards compatibility, it's > > a bug fix. > > Disagreement on whether changing the default for certificate validation > is a 'bugfix' or 'enhancement' (and in the colloquial or python tracker > sense) the seems like the crux of the disagreement here. The case for > 'bug', at least in the colloquial meaning, is at least plausible. On the > other hand, the tracker meaning of 'behavior' issue (contrary to > intention and doc) is more strict in including implementation bugs but > not necessarily design bugs.
Up to this point the suggestion has been to change the default only in 3.5, and what we are arguing about is what kind of and how much aid to give to those for whom 3.5 breaks backward compatibility. So arguing about feature versus bug is irrelevant. The top proposal so far is an sslcustomize.py file that could be used to either decrease or increase the default security. This is a much less handy solution than application options (eg, curl, wget) that allow disabling security for "this cert" or "this CLI session". It also is more prone to unthinking abuse since it is persistent. So perhaps it is indeed not worth it. (That's why I suggested an environment variable...something you could specify on the command line for a one-off.) The more I think about it the less I like sslcustomize. I think I'd rather do without the ability to turn off checking without modifying code rather than introduce an intentional vector for a system-wide decrease in security. --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