Antoine Pitrou <pit...@free.fr> added the comment: > I think it is kind of OK to require explicit specification of the > ca_certs as long as it is made clear in all the relevant places that > it _has_ to be done. I think it would be a good idea to deprecate the > default value for ca_certs and issue a warning if ca_certs hasn't been > specified (as None or a path).
The recommended way from Python 3.2 upwards is to define a SSLContext and use it when doing SSL operations. Many APIs have been updated to accept a context, a few are remaining as I've said in my first comment. > I have heard that some Python variants come with the system ca_certs > built in and hard-coded somehow. This is really "some OpenSSL variants" rather than "some Python variants". We can't control how the system (or user-supplied) OpenSSL is built. This "feature" is exposed in SSLContext.set_default_verify_paths() (see http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths), with the caveat that you don't know whether it succeeded at all. > That is in a way very nice and convenient and a good solution (as long > the user wants to use the same ca_certs for all purposes), but it > would have to be available and reliable on all platforms to be really > useful. Well, for one, it probably won't be effective on Windows builds, since it's really not Python's job to define a set of reliable CA certificates (unless Martin wants to take that responsibility, that is), and Windows doesn't have a set of system certificates in the PEM format AFAIK. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10795> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com