[Python-Dev] PEP 466: Proposed policy change for handling network security enhancements (original) (raw)
Chris Angelico rosuav at gmail.com
Tue Mar 25 10:01:42 CET 2014
- Previous message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Next message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Mar 25, 2014 at 7:37 PM, Cory Benfield <cory at lukasa.co.uk> wrote:
On 25 March 2014 08:26, Chris Angelico <rosuav at gmail.com> wrote:
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. Reading this I suspect we're mostly in agreement but having trouble communicating. My understanding of your point is simply that you don't want python-dev to 'bless' either of the 2.7 releases proposed as the 2.7 release, instead pushing that choice on to people distributing Python. I can get behind that plan so long as the source code releases are named in such a way that people are either a) forced to make a choice; or b) defaulted to secure 2.7.
I'd like python.org / python-dev to bless, if not some specific version, at least some specific structure. I think that's something like what has been in the PEP at some point, though I haven't dug into the current version deeply enough to be sure. But if you take current 2.7 as a baseline, every new feature would be implemented by creating a new attribute of either the ssl module or some class in it; if the attribute is there, you can use it (eg a constant/enum value that's a parameter to something else), and if it's not, you can't. As long as the names are consistent, it'd be easy for a program to either probe and use what it can get, or just use what it wants and bomb if you don't give it a sufficiently-secure Python.
So by that model, current 2.7 is fully compliant, and anything that doesn't actively conflict with that is also compliant. Any script that is written for the current 2.7 is guaranteed also to run on any compliant SEPython; and anything written for SEPython has to gracefully handle (which might mean cleanly bombing) anything down to and including current 2.7. Does that make sense?
ChrisA
- Previous message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Next message: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]