Author gvanrossum
Recipients christian.heimes, gvanrossum, pitrou
Date 2013-10-19.16:02:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <1382183555.2517.7.camel@fsol>
@Christian: What is holding up those patches? I don't believe we should be
in the business of distributing certificates -- we should however make it
easy to use the system certificates.

@Antoine: I still claim that a flag that defaults to no security is a
vulnerability -- nobody reads warnings in docs until *after* they've been
bitten. It should be an explicit choice in the script or app to disable
certificate checking. If you can't access a server because its certificate
is expired, how is that different than any other misconfiguration that
makes a server inaccessible until its administrator fixes it?

On Sat, Oct 19, 2013 at 4:53 AM, Antoine Pitrou <>wrote:

> Antoine Pitrou added the comment:
> > Why is this not a security patch? Because it's not a "vulnerability"
> > in the narrow technical sense? I expect that it will greatly increase
> > the actual practical security, by making it easier to do the right
> > thing.
> IMO it's not a vulnerability. It's not a security hole in Python: the
> flag is there for people to turn on or off, and the whole thing is
> documented (with a highly visible red warning). The situation is
> actually much better than in 2.7.
> I would also like to point out Python isn't a Web browser: its use cases
> are wider, and there's no default interactive UI to allow the user to
> bypass certificate issues (which are still common nowadays on the
> Internet). I think it makes it much less appropriate to be "strict by
> default".
> ----------
> _______________________________________
> Python tracker <>
> <>
> _______________________________________
Date User Action Args
2013-10-19 16:02:19gvanrossumsetrecipients: + gvanrossum, pitrou, christian.heimes
2013-10-19 16:02:19gvanrossumlinkissue19292 messages
2013-10-19 16:02:18gvanrossumcreate