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

[Chris Angelico]

On Sun, Mar 23, 2014 at 10:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 22 Mar 2014 19:07:51 -0400
> Donald Stufft <donald at stufft.io> wrote:
>> As someone who is deeply biased towards improving the packaging tool chain and getting people to use it I think that most people will simply use the Stdlib even if a more secure alternative exists. Infact one does exist and I still see almost everyone using the stdlib ssl instead of pyopenssl.
>
> pyopenssl exposes a different API from ssl, though. It's not just a
> matter of flipping an import statement.

How hard would it be to create a wrapper module named "ssl.py", which
imports pyopenssl (thus taking advantage of any updates it gets), and
could be placed earlier in the search path than the stdlib one?

I'm +1 on the overall concept, but not sure about 2.6 and older. 2.7
is already a bit of an odd duck; it's being supported for longer than
its official Windows compiler, it's going to be supported by Red Hat
until eternity and beyond, and it wouldn't in the least surprise me if
2.7.10 introduces a bit of stuff, backported, in ways that are
fundamentally security fixes.

Is it really that bad to have something depend on "2.7.10" rather than
"2.7.0"? If a program will bomb without some bugfix, then it's not
unreasonable to say that it depends on a version of Python that
includes that fix. As long as any program written for 2.7.0 will run
on 2.7.x unchanged (the normal expectations with semantic versioning),
I don't see a problem with some of the "bug fixes" actually adding
attributes; imagine if some feature attribute were simply misspelled
in the previous versions, which could surely be fixed in a point
release; it's not going to break anything.

ChrisA