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

Cory Benfield cory at lukasa.co.uk
Tue Mar 25 09:12:51 CET 2014

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.

More information about the Python-Dev mailing list