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

Chris Angelico rosuav at gmail.com
Tue Mar 25 09:26:08 CET 2014

On Tue, Mar 25, 2014 at 7:12 PM, Cory Benfield <cory at lukasa.co.uk> wrote:

On 24 March 2014 19:37, Chris Angelico <rosuav at gmail.com> wrote:

The opting in could be done at the distro level. Red Hat could ship a thing called /usr/bin/python that runs SEPython, and that package could be identified and numbered in such a way that it's clearly a drop-in replacement for vanilla Python. If backward compatibility is done carefully (which, from everything I'm seeing here, is the way it's to be done), there should be absolutely no downside to using SEPython, except for portability (because now you're depending on it for security), and corner cases like testing. What's your solution for OS X, Windows et al? My concern is that if you have a release called 'Python' and a release called 'Python with security stuff', a surprisingly large number of people will download the first, especially if the notes for the security release say 'this may cause some minor compatibility problems'. IMHO, I'd rather have good security be the default for everyone, and require an explicit opt-out to get the bad security release.

Exactly the same. If someone wants to distribute SEPython (that someone might be python.org itself, or ActiveState, or anyone else who has an interest in it), they're welcome to do so; and it could be done either as an all-in-one that packages all of CPython, or as an add-on; either way would work just as well, but the former would be cleaner.

ChrisA

More information about the Python-Dev mailing list