@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 <report@bugs.python.org>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 <report@bugs.python.org>
> <http://bugs.python.org/issue19292>
> _______________________________________
>