> While the normal deprecation process should suffice, that still means Python > 3.6 (2017-ish) is the earliest feasible target for new default settings.
Could a CERT_NOVERIFY no-op be added now? (no-op because it would just be more explicit about the default behavior anyway) [1] > 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). Could/should this be a feature of 2to3? [1] (and/or automated AST code scanners for Python source)? [1] https://mail.python.org/pipermail/python-dev/2014-January/131974.html > 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. I'm aware of aiohttp (BSD), but haven't yet had much chance to review the source. It looks like the tests currently require nose and gunicorn, because it provides an asyncio gunicorn worker. "http client/server for asyncio" https://github.com/fafhrd91/aiohttp -- Wes Turner On Wed, Jan 22, 2014 at 4:20 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 23 Jan 2014 07:48, "Donald Stufft" <don...@stufft.io> wrote: >> >> Never mind. If someone else cares they can propose it. I withdraw. > > 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. > > 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. > > 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. > > While the normal deprecation process should suffice, that still means Python > 3.6 (2017-ish) is the earliest feasible target for new default settings. > > 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). > > 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. > > Regards, > Nick. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
