On 30 Aug 2014 06:08, "Ethan Furman" <email@example.com> wrote:
> On 08/29/2014 01:00 PM, M.-A. Lemburg wrote:
>> On 29.08.2014 21:47, Alex Gaynor wrote:
>>> I've just submitted PEP 476, on enabling certificate validation by default for
>>> HTTPS clients in Python. Please have a look and let me know what you think.
>> Thanks for the PEP. I think this is generally a good idea,
>> but some important parts are missing from the PEP:
>> * transition plan:
>> I think starting with warnings in Python 3.5 and going
>> for exceptions in 3.6 would make a good transition
>> Going straight for exceptions in 3.5 is not in line with
>> our normal procedures for backwards incompatible changes.
>> * configuration:
>> It would be good to be able to switch this on or off
>> without having to change the code, e.g. via a command
>> line switch and environment variable; perhaps even
>> controlling whether or not to raise an exception or
>> * choice of trusted certificate:
>> Instead of hard wiring using the system CA roots into
>> Python it would be good to just make this default and
>> permit the user to point Python to a different set of
>> CA roots.
>> This would enable using self signed certs more easily.
>> Since these are often used for tests, demos and education,
>> I think it's important to allow having more control of
>> the trusted certs.
> +1 for PEP with above changes.
Ditto from me.
In relation to changing the Python CLI API to offer some of the wget/curl style command line options, I like the idea of providing recipes in the docs for implementing them at the application layer, but postponing making the *default* behaviour configurable that way.
Longer term, I'd like to actually have a per-runtime configuration file for some of these things that also integrated with the pyvenv support, but that requires untangling the current startup code first (and there are only so many hours in the day).
> Python-Dev mailing list
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com