[Python-Dev] PEP 476: Enabling certificate validation by default! (original) (raw)

R. David Murray rdmurray at bitdance.com
Wed Sep 3 03:29:16 CEST 2014


On Tue, 02 Sep 2014 20:59:54 -0400, Terry Reedy <tjreedy at udel.edu> wrote:

On 9/2/2014 7:47 PM, Glyph Lefkowitz wrote: > > On Sep 2, 2014, at 4:28 PM, Nick Coghlan <ncoghlan at gmail.com_ _> <mailto:ncoghlan at gmail.com>> wrote: > >> On 3 Sep 2014 09:08, "David Reid" <dreid at dreid.org_ _>> <mailto:dreid at 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



More information about the Python-Dev mailing list