Home Original page

[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?

--
~Ethan~
More information about the Python-Dev mailing list