[Python-Dev] PEP 476: Enabling certificate validation by default!

[R. David Murray]

On Mon, 01 Sep 2014 08:10:58 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 1 Sep 2014 07:43, "Christian Heimes" <christian at 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