[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

[Nick Coghlan]

On 23 Mar 2014 11:47, "Donald Stufft" <donald at stufft.io> wrote:
>
>
> On Mar 22, 2014, at 9:33 PM, Brett Cannon <bcannon at gmail.com> wrote:
>
>>
>>
>> On Sat Mar 22 2014 at 8:55:36 PM, Nick Coghlan <ncoghlan at gmail.com>
wrote:
>>>
>>> On 23 March 2014 10:08, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>> > On Sat, 22 Mar 2014 23:54:37 +0100
>>> > Thomas Wouters <thomas at python.org> wrote:
>>> >>
>>> >> Or not rely on the standard library for their security. Much as I
realize
>>> >> it is necessary for rudimentary SSL support (for example) to exist
in the
>>> >> standard library,
>>> >
>>> > Unfortunately, "rudimentary SSL support" is worse than nothing.
>>>
>>> I'm going to try to find a way to steal that line and get it into the
>>> PEP. I'm not sure yet if my proposal is the *right* answer, but this
>>> observation gets right to the heart of the problem that actually needs
>>> to be solved.
>>>
>>> I'd actually welcome a competing PEP that seriously explored
>>> separating out the relevant parts of the Python 3.4 standard library
>>> as a PyPI project and attempted to tackle the problem by making that
>>> available at least as far back as 2.7 and then just deprecating the
>>> leaking batteries in the 2.7 standard library.
>>
>>
>> Now I have been reading this thread on my phone and I only have cursory
understanding of what failure ssl has had as of late, so this might be
stupid, but what if in Python 3.5 we made it so people passed in an
explicit SSL object into the relevant APIs and threw an exception if one
wasn't provided when trying to access something requiring SSL? Then the ssl
module would start existing on PyPI to make sure it can evolve faster than
every 18 months?
>
>
> It's not really a failure so much as what was concerned secure in 2010
isn't the case in 2014.
>
> I don't want to sounds like I'm trying to say that pip should dictate
Python policy or anything
> but pip more or less depends on the fact that ssl is available in the
stdlib at this point in time
> in order to be able to handle secure downloads.
>
> Every 18 months isn't that big of a deal tbh, the larger concern is
Python 2.7 which has had
> nearly 4 years since it's release and is likely to exist for far more
years past that.

Yes, I think it's worth narrowing the scope to just Python 2.7, and leaving
the process unchanged for 3.x.

Cheers,
Nick.

>
>>
>> I know this doesn't help older APIs but it would make it rather explicit
going forward that if you want security you need the latest thing and
that's found on PyPI so it would at least solve the issue for the future
which is better than nothing. We could try to provide matching APIs that
monkey-patch older versions of Python if that's so desired to make this
backwards-compatible, but as we all know that can be rather brittle.
>>
>> -Brett
>>
>>>
>>>
>>> Just because I think that approach would be even more work and even
>>> more disruptive than what I propose in PEP 466, doesn't mean it isn't
>>> a better idea overall.
>>>
>>> What we have essentially found is that where we could basically get
>>> away with an 18 month update cycle for improved network security
>>> support (extended out to a few years by certain major platform
>>> vendors), that approach *isn't* working when it comes to putting a
>>> feature release into long term maintenance mode. I don't think the
>>> situation isn't critical yet, but it's getting close, and I think we
>>> need to deal with it within the 12 months (and preferably sooner than
>>> that).
>>>
>>> My PEP proposes one way of addressing the challenge: allowing a wider
>>> variety of changes in maintenance releases to reduce the variance in
>>> capability in this area.
>>>
>>> Moving the affected modules out of the standard library proper and
>>> bundling the critical ones along with pip instead is indeed another
>>> alternative. However, that approach introduces additional issues of
>>> its own - I'll cover some of them in the next PEP update, but it would
>>> be good to have someone explicitly trying to make the case that a PyPI
>>> backport would be simpler for the overall ecosystem than my suggested
>>> approach.
>>>
>>> Cheers,
>>> Nick.
>>>
>>>
>>> --
>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
>
>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140323/891446c4/attachment-0001.html>