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

[Cory Benfield]

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.