> @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.