<p dir="ltr"><br>
On 23 Jan 2014 07:48, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
> Never mind. If someone else cares they can propose it. I withdraw. </p>
<p dir="ltr">That's unfortunate, but understandable - we already have a lot to deal with just trying to get even the software distribution infrastructure to a "secure by default" status.</p>
<p dir="ltr">However, now we have access to the system cert stores on all major platforms, I *do* think it's a good idea to eventually change the default settings to include host verification.</p>
<p dir="ltr">It's just any such concrete proposal, like any other major backwards incompatible change, needs to be written up as a PEP, including a transition plan for insecure environments where users will blame *Python* if an upgrade breaks things, rather than the insecurity of their configuration. We know all too well from the Python 3 transition how unhappy it makes users when a new version complains about environmental issues that previous versions blithely ignored.</p>

<p dir="ltr">While the normal deprecation process should suffice, that still means Python 3.6 (2017-ish) is the earliest feasible target for new default settings.</p>
<p dir="ltr">Such a proposal will also need to address the implications for source compatible Python 2/3 code across *all* secure network protocols, not just HTTPS (the latter can be handled relatively easily using the requests module).</p>

<p dir="ltr">A new, preferred, secure-by-default HTTPS client API for the standard library (based on the requests API) is an orthogonal proposal, and one that already has in-principle approval from Guido, preferably as a synchronous front end to the asyncio networking backend.</p>

<p dir="ltr">Regards,<br>
Nick.</p>