So you agree that we should change the urllib default in 3.4? I'm all for
that.

Tools like svn and hg have extensive configurations for this purpose, and
(at least hg) secure defaults; I certainly remember having to deal with hg
complaining about the security of some repo site, where the fix was
something I had to put in my .hgrc. That's interactive enough.

These days, I wouldn't trust a site that lets its certificate expire with
anything important.

On Sat, Oct 19, 2013 at 9:22 AM, Antoine Pitrou <report@bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > @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 we were introducing urllib right now, I agree it would be better to
> be "secure by default". But urlopen() has been there for a long time,
> it's used a lot and changing the default will break some of the scripts
> or apps that have been working fine for ages.
>
> > 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?
>
> It's different because the server isn't inaccessible. Its HTTPS service
> works fine, it's just that the certificate is untrustable according to
> some chosen security settings.
>
> (besides, an expired certificate is not a "misconfiguration"; it worked
> fine until it expired; not all systems have dedicated paid
> administrators, so this situation is not uncommon)
>
> Again, I think it may be reasonable to change in 3.4, but not in bugfix
> versions.
>
> By the way, I seem to remember even svn.python.org used a CACert-emitted
> certificate during a long time... a cert that wasn't validated by major
> browsers.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue19292>
> _______________________________________
>