On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:
The data is analogous to the time zone database (PEP 431) in that it may
need to be updated independently of Python's own release schedule, so we
may want to use similar techniques to manage both. Also see certifi (
https://pypi.python.org/pypi/certifi), which is a copy of the Mozilla list
in a pip-installable form.
Right, this is very much analogous, except with the additional twist that
out-of-date certificates can pose a significant security risk.
I'm fairly certain that Debian and Ubuntu would explicitly not use any
certificates shipped with Python, for two main reasons: 1) our security teams
already manage the certificate store distro-wide and we want to make sure that
one update fixes everything; 2) we don't want to duplicate code in multiple
packages[1].
So *if* Python decides to do this (and I'm -0, but from a decidedly
Linux-distro bias), it must be easily disabled. I generally like the way PEP
431 handles the tzdata, so I think we should do the same here.
I'd actually prefer for Linux to not use the bundled certs when installed from a package
manager because it should use the system certs, but people can't depend on certs
being there if they are only there on linux.
Adding them into Python means people _can_ depend on them being there, and Windows
and other systems without system integrators to modify it to use the system store will still
get certs and Ubuntu can make it just work(™).
-Barry
[1] This gives us headaches in upstreams like coverage caused by bundling
externally available JavaScript libraries, or like urllib3 bundling chardet
and urllib3, not to mention their own certificates yet again. :(
This would probably (eventually) make the bundling of certificates better too.
Meaning that once it's been in long enough people are willing to depend on it, they
won't need to bundle their own certs and ubuntu/debian can just modify the one
location instead of needing to modify it for every package that does it.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io