On 24 Mar 2014 09:27, "Barry Warsaw" <barry@python.org> wrote:
>
> On Mar 23, 2014, at 01:01 AM, Antoine Pitrou wrote:
>
> >But enforcing "secure by default" can by construction break backwards
> >compatibility, which is the very reason we are so conservative with
> >such changes.
>
> Also, many developers who are stuck on Python 2 have already evaluated,
> designed, and implemented workarounds for security issues in ancient stdlib
> code.  You have to be very careful that any changes in some future 2.7 stdlib
> secure-by-default release doesn't break those workarounds.  That's a "trick
> question" too because you can't know all of them.
>
> I didn't read the PEP until just now, so I never saw the first draft.  As
> written it still makes me uncomfortable because as Antoine says, lots of
> changes could be classified as "security related" and we definitely don't want
> this PEP to be used as a wedge to make a wink-wink-nudge-nudge release of
> Python 2.8.

Hence why the proposal mostly *isn't* scoped by "security related". It is scoped by "affects the security design of other systems, including systems not written in Python". The core problem to be solved is ensuring that the "cold, dead hand" of the Python 2 standard library doesn't hold back the evolution of internet security standards.

I'm starting to think it makes sense to drop the higher level abstractions from the proposal, though. Once the core SSL support issue is addressed, it's comparatively straightforward to handle any other cases as PyPI modules if needed. pip, for example, already bundles requests to handle HTTPS, but that still relies on the stdlib SSL support.

> I think the key point for consumers of Python has to be *predictability*.

Agreed. That's a key part of why the proposal is mainly about syncing certain key modules with their Python 3 counterparts, rather than piecemeal backports. That way, all you need to know is "the SSL, hashlib and hmac modules are kept in sync with Python 3 feature releases, but use the same default settings as the original Python 2.7 release". A partial backport is actually *harder* for users to deal with (another reason I'm quite amenable to dropping that part of the proposal).

Cheers,
Nick.

>
> -Barry
> _______________________________________________
> 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/ncoghlan%40gmail.com