[Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

Ethan Furman ethan at stoneleaf.us
Mon Jun 3 20:15:51 CEST 2013

On 06/03/2013 10:55 AM, Donald Stufft wrote:
> On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
>> On 06/03/2013 09:43 AM, Donald Stufft wrote:
>>> On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
>>>> The problem with a "slightly outdated" CA store is that it can be a
>>>> security risk.
>>> Tracking the Mozilla store isn't difficult. New additions can be ignored for currently released Pythons so we'd just
>>> need to watch them for blacklisting certs and roll that into a security update.
>> Personally, I'm not interested in waiting six months for an update.  And why can't I have the new additions?
>> Seems to me a better solution is to have routines that can query and update at will (meaning the app has to call
>> them), as well as having the bundle (black lists as well as new additions) in the regular updates.
> Personally I view that as a nice to have but if an app is willing to call hem they can easily depend on certifi and just
> replace the default certificates. The goal here is to get secure by default without any work on the part of the
> developers. If a developer knows to update the certs they can know to use certifi.

Let's pretend I want to do something with https.  I'm pretty much a complete novice in that area, but I do know about 
these certificate things and that I should use them.  (Which will probably happen sooner rather than later. ;)

 From my POV, having the bundled certs in the stdlib is great, but also having something in the stdlib to query for and 
download updates would also be great.  I just looked at certifi and the only thing it has on there is `where` which 
tells me where the certs are on the system.  This on only half the problem.  If we're going to solve it, why not solve 
the whole problem?


More information about the Python-Dev mailing list