On Mon, 01 Sep 2014 08:10:58 +1000, Nick Coghlan <ncogh...@gmail.com> wrote: > On 1 Sep 2014 07:43, "Christian Heimes" <christ...@python.org> wrote: > > > > On 31.08.2014 08:09, Nick Coghlan wrote: > > > As Antoine says here, I'm also opposed to adding more Python specific > > > configuration options. However, I think there may be something > > > worthwhile we can do that's closer to the way browsers work, and has > > > the significant benefit of being implementable as a PyPI module first > > > (more on that in a separate reply). > > > > I'm on your and Antoine's side and strictly against any additional > > environment variables or command line arguments. That would make the > > whole validation process even more complex and harder to understand. > > > > There might be a better option to give people and companies the option > > to tune the SSL module to their needs. Python already have a > > customization hook for the site module called sitecustomize. How about > > another module named sslcustomize? Such a module could be used to tune > > the ssl module to the needs of users, e.g. configure a different default > > context, add certificates to a default context etc. > > > > Companies could install them in a system global directory on their > > servers. Users could put them in their own user site directory and even > > each virtual env can have one sslcustomize of its own. It's fully > > backward compatible, doesn't add any flags and developers have the full > > power of Python for configuration and customization. > > And means a user specific store (if one became available) could be > configured there. > > Yes, I think this would address my concerns, especially if combined with a > clear recipe in the documentation on how to optionally disable cert > validation at the application layer. > > Assuming sslcustomize was in site-packages rather than the standard library > directories, you would also be able to use virtual environments with an > appropriate sslcustomize module to disable cert checking even if the > application you were running didn't support direct configuration.
It sounds like this would address my concerns as well (I don't really care *how* it is implemented as long as I don't have to touch the code of a third party application when I upgrade my python version to 3.5...remember, the context here is backward compatibility concerns). Does it address the issue of accepting an invalid cert, though? --David _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com