[Python-Dev] PEP 476: Enabling certificate validation by default!

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