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 <rep...@bugs.python.org> <http://bugs.python.org/issue19292> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com