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

Cory Benfield cory at lukasa.co.uk
Sun Aug 31 12:42:12 CEST 2014

On 31 August 2014 07:45, Nick Coghlan <ncoghlan at gmail.com> wrote:
> There's also the fact that most corporate Python users are
> unlikely to know that PyPI exists, let alone that it contains a module
> called "requests" that does SSL certificate validation by default.
> Those of us in the corporate world that interact directly with
> upstream are still the exception rather than the rule)

I think this point deserves just a little bit more emphasis. This is
why any solution that begins with 'use PyPI' is insufficient. I've
worked on requests for 3 years now and most of my colleagues have
never heard of it, and it's not because I don't talk about it (I talk
about it all the time!).

When building internal tools, corporate environments frequently
restrict themselves to the standard library. This is because it's hard
enough to get adoption of a tool when it requires a new language
runtime, let alone if you have to get people ramped up on package
distribution as well! I have enough trouble getting people to upgrade
Python versions at work: trying to get them up to speed on pip and
PyPI is worse.

It is no longer tenable in the long term for Python to trust the
network: you're right in this regard Nick. In the past, on this very
list, I've been bullish about fixing up Python's network security
position. I was an aggressive supporter of PEP 466 (and there are some
corners of PEP 466 that I think didn't go far enough). However, I'm
with you here: we should do this once and do it right. Corporate users
*will* bump into it, and they will look to the docs to fix it. That
fix needs to be easy and painless.

A user-level cert store is a good start, and if cryptography.io aren't
interested in it I might take a look at implementing it under the
certifi.io umbrella instead.


More information about the Python-Dev mailing list