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

Thomas Wouters thomas at python.org
Sat Mar 22 23:54:37 CET 2014


On Sat, Mar 22, 2014 at 11:26 PM, "Martin v. Löwis" <martin at v.loewis.de>wrote:

> Am 22.03.14 23:21, schrieb Donald Stufft:
> > "Just use Python 3.4" ignores the reality of production software. I wish
> it were that simple because I love 3.4
>
> But I think so does the PEP (i.e. ignore the reality of production
> software). The risk of breaking existing installations (which might
> not be affected by the purported security threat being fixed) is just
> too high.
>
> Users that feel threatened by the lack of SSL features in Python should
> have long started planning on how to get to Python 3. It's not that they
> haven't been warned.


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, any security-aware user is much better served by
third-party packages they can update more easily than Python. I really wish
we had no SSL *server* support in the standard library at all (but then I
wish we didn't have so many middling-quality servers in the stdlib to start
with :)

Even when we're not considering virtualenvs, which are a great tool for
preventing upgrades from breaking things, separately-installed packages (be
they third-party or "official" python.org packages) are much easier to
upgrade than whole Python installations. And a third-party package like
PyOpenSSL has much more freedom in dealing with backward-incompatible
changes (because users updating PyOpenSSL are much more likely to realize
something regarding SSL could break, even if they aren't more likely to
read the release documentation.)

I think I'm +0 on the PEP: I understand Martin's concerns, and share them
(heck, I'm preparing for an update from Python 2.7.3 to 2.7.6 at work and
I'm already having nightmares) but I also understand the problem the PEP
tries to solve. I wish we would separate out e.g. the SSL-related modules
so they aren't part of the 'core' Python but not quite third-party packages
either, but that's not something that's easily done. I do believe that
besides accepting this PEP we should provide good guidance on how to write
portable, secure software using the tools provided, say in a new chapter in
the library docs -- and it shouldn't be afraid to suggest third-party
modules if they are a much better solution :)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140322/1de5d188/attachment.html>


More information about the Python-Dev mailing list