On Mon, 03 Jun 2013 19:38:45 +1200, Ben Hoyt <benhoyt@gmail.com> wrote:
Love this idea. Some third-party HTTP libraries turn this on by default in any case (eg: requests, and I think others), so this would mean Python would get their "safe-by-default" behaviour in its stdlib.
Ideally this would take the shape of attempting to locate the system certificate store if possible, and if that doesn't work falling back to the bundled certificates. That way the various Linux distros can easily have their copies of Python depend soley on their built in certs, but Windows, OSX, Source compiles etc will all still have a fallback value.
My preference would be actually be for the included certificates file to be used by default. This would provide a consistent experience across platforms. We could provide options to look for system cert repositories if desired.
Very much agreed. When the Windows version of the mimetypes module tried to use Windows' system mimetype mappings by default, chaos and bugs ensued (for example, http://bugs.python.org/issue15207 and http://bugs.python.org/issue10551).
On the other hand, the fact that it uses /etc/mimetypes on unix does *not* cause chaos, quite the opposite: it means Python recognizes new mime types provided by the distro automatically, which provides for a more consistent experience for the Python application user. The situation for certs is probably fairly parallel: on unix, it would probably be an advantage as Python would automatically follow distro decisions about cert chains, while on windows trying to use a system cert store would probably be a disaster. An application can choose to explicitly ignore the system mimetypes file, by the way. That said, I don't feel strongly either way about the cert store case. --David