Am 03.06.2013 07:20, schrieb Donald Stufft:
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.
On Windows it's rather easy to access the cert storage with a couple of calls to crypt32.dll. I have created a smallish ctypes interface: https://bitbucket.org/tiran/wincertstore/overview . setuptools 0.7 is using it to for its ssl support. I'm going to write a patch for Python 3.4, too. See http://bugs.python.org/issue17134 I welcome a cert bundle in CPython. But how are we suppose to handle updates and invalidation of CAs? A couple of months ago there was an intense discussion about a copy of the Olson time zone database in Python's stdlib. People argued against it as they feared outdated tz information. IMHO outdated CA certs are much more severe than tz ... I'd like to see OCSP support, too. Unfortunately OpenSSL's OCSP API is far from trivial. I had a look at it once. Christian