On Sat, Mar 22, 2014 at 11:26 PM, "Martin v. Löwis"
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