Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Mon, 24 Mar 2014 10:10:18 +0100 M.-A. Lemburg m...@egenix.com wrote: The OpenSSL version used for 2.7.6 is 0.9.8y. Upgrading to 1.0.0 or 1.0.1 will likely need a few minor tweaks, but not cause general breakage - at least that's my experience with the egenix-pyopenssl distribution. For the record, if we had done that a few months ago, the breakage would have been called Heartbleed. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 25 March 2014 09:04, Donald Stufft don...@stufft.io wrote: On Mar 24, 2014, at 5:38 PM, Nick Coghlan ncogh...@gmail.com wrote: While I totally agree that it would be incredibly awesome if more companies put dedicated time into developing and maintaining CPython I don't think pushing all the blame on to them is accurate. The attitude towards security issues and backwards compatibility has a somewhat equal share in the causes of the aging security infrastructure of the 2.x line. Now this PEP, if accepted, does a lot to resolve the largest offenders of this policy (and there has been some signs lately that perhaps going forward this will be better) but I think it is not doing anyone a favor if we just point fingers *over there* and claim the fault lies with someone else doing or not doing something. I *don't* want to disparage anyone or anything of that like, mostly to say that while of course increased resources from corporate users would help the situation immensely but that additionally there is a reasonably sized contingent of influential members who still want to treat Python as a hobbyist project and not a critical piece of the infrastructure of the Internet as a whole. I *don't* want to get help from downstream users, especially on important but boring or hard issues such as security, and then have them feel shutdown and unable to actually get anything done as others who have attempted to resolve some of these issues in the past have had happen to them. I actually agree with this (hence why I wrote the PEP in the first place), I just became really, really, really, annoyed with certain organisations over the course of writing the PEP drafts and that is reflected in the tone of the latest draft. However, in deliberately not naming names, I now realise I've left it open to *other* organisations thinking Does he mean us? How is this our fault?. For clarification: if an org is guessing whether or not I was referring to them in particular while drafting the PEP, then no, I'm not. The specific organisations concerned are in absolutely no doubt as to the fact I'm genuinely angry with them. That said, while it certainly made me feel better at the time, I agree some of the current phrasing is not actually helpful in resolving the situation amicably for the benefit of all concerned, so I'll revise the offending sections of the PEP :) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Mar 25, 2014, at 06:11 PM, Nick Coghlan wrote: I actually agree with this (hence why I wrote the PEP in the first place), I just became really, really, really, annoyed with certain organisations over the course of writing the PEP drafts and that is reflected in the tone of the latest draft. However, in deliberately not naming names, I now realise I've left it open to *other* organisations thinking Does he mean us? How is this our fault?. For clarification: if an org is guessing whether or not I was referring to them in particular while drafting the PEP, then no, I'm not. The specific organisations concerned are in absolutely no doubt as to the fact I'm genuinely angry with them. That said, while it certainly made me feel better at the time, I agree some of the current phrasing is not actually helpful in resolving the situation amicably for the benefit of all concerned, so I'll revise the offending sections of the PEP :) Anger management through PEP writing! That's novel, but I can show you some more effective techniques at Pycon. :) -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 23.03.2014 08:07, Nick Coghlan wrote: Open Questions == * What are the risks associated with allowing OpenSSL to be updated to new feature versions in the Windows and Mac OS X binary installers for maintenance releases? Currently we just upgrade to the appropriate OpenSSL maintenance releases, rather than switching to the latest feature release. In particular, is it possible Windows C extensions may be linking against the Python provided OpenSSL module? Python's _ssl/_hashlib modules link statically against OpenSSL in Python 2.7, so the OpenSSL DLLs are not exposed to other extensions. The OpenSSL version used for 2.7.6 is 0.9.8y. Upgrading to 1.0.0 or 1.0.1 will likely need a few minor tweaks, but not cause general breakage - at least that's my experience with the egenix-pyopenssl distribution. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 24 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-03-29: PythonCamp 2014, Cologne, Germany ... 5 days to go 2014-04-09: PyCon 2014, Montreal, Canada ... 16 days to go 2014-04-29: Python Meeting Duesseldorf ... 36 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
Le 24/03/2014 10:10, M.-A. Lemburg a écrit : On 23.03.2014 08:07, Nick Coghlan wrote: Open Questions == * What are the risks associated with allowing OpenSSL to be updated to new feature versions in the Windows and Mac OS X binary installers for maintenance releases? Currently we just upgrade to the appropriate OpenSSL maintenance releases, rather than switching to the latest feature release. In particular, is it possible Windows C extensions may be linking against the Python provided OpenSSL module? Python's _ssl/_hashlib modules link statically against OpenSSL in Python 2.7, so the OpenSSL DLLs are not exposed to other extensions. I suppose you mean under Windows. Under Linux (and probably OS X too), the _ssl module is linked dynamically with OpenSSL: $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so linux-vdso.so.1 = (0x7fff3f1de000) libssl.so.1.0.0 = /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7fd8853ea000) libcrypto.so.1.0.0 = /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fd88501) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd884df1000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000) /lib64/ld-linux-x86-64.so.2 (0x7fd885868000) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 24.03.2014 13:33, Antoine Pitrou wrote: Le 24/03/2014 10:10, M.-A. Lemburg a écrit : On 23.03.2014 08:07, Nick Coghlan wrote: Open Questions == * What are the risks associated with allowing OpenSSL to be updated to new feature versions in the Windows and Mac OS X binary installers for maintenance releases? Currently we just upgrade to the appropriate OpenSSL maintenance releases, rather than switching to the latest feature release. In particular, is it possible Windows C extensions may be linking against the Python provided OpenSSL module? Python's _ssl/_hashlib modules link statically against OpenSSL in Python 2.7, so the OpenSSL DLLs are not exposed to other extensions. I suppose you mean under Windows. Yes. Should have included that detail in the email :-) Under Linux (and probably OS X too), the _ssl module is linked dynamically with OpenSSL: $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so linux-vdso.so.1 = (0x7fff3f1de000) libssl.so.1.0.0 = /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7fd8853ea000) libcrypto.so.1.0.0 = /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fd88501) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd884df1000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000) /lib64/ld-linux-x86-64.so.2 (0x7fd885868000) Right, and it's using the system library, not a private copy - which can be both good and bad depending on how recent the system's library version is. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 24 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-03-29: PythonCamp 2014, Cologne, Germany ... 5 days to go 2014-04-09: PyCon 2014, Montreal, Canada ... 16 days to go 2014-04-29: Python Meeting Duesseldorf ... 36 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 24 March 2014 22:39, M.-A. Lemburg m...@egenix.com wrote: On 24.03.2014 13:33, Antoine Pitrou wrote: Under Linux (and probably OS X too), the _ssl module is linked dynamically with OpenSSL: $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so linux-vdso.so.1 = (0x7fff3f1de000) libssl.so.1.0.0 = /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7fd8853ea000) libcrypto.so.1.0.0 = /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7fd88501) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd884df1000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd884a2b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd884827000) /lib64/ld-linux-x86-64.so.2 (0x7fd885868000) Right, and it's using the system library, not a private copy - which can be both good and bad depending on how recent the system's library version is. Even if *we* statically linked OpenSSL on Linux, you can bet distro vendors would switch it back to dynamic linking. Hence the comment in the PEP about vendor provided OpenSSL updates mitigating some of the concerns on Linux (defaulting not all of them though - it's still far too easy for developers to make mistakes and too hard from them to do the right thing from a security perspective). You also reminded me that I need to dig around for and reference Ned's email about the status of OS X and reference that (OpenSSL upgrades were a casualty of Apple's anti-GPL crusade, so the OS X installers were switched to static linking somewhere along the line). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
In article cadisq7f0cnzrfm4i8xj13j+slq63uynqkdo12czm5yeq3bf...@mail.gmail.com, Nick Coghlan ncogh...@gmail.com wrote: You also reminded me that I need to dig around for and reference Ned's email about the status of OS X and reference that (OpenSSL upgrades were a casualty of Apple's anti-GPL crusade, so the OS X installers were switched to static linking somewhere along the line). AFAIK, Apple's decision to deprecate OpenSSL has nothing to do with the GPL, since OpenSSL isn't GPL-licensed, but rather with OpenSSL API compatibility issues: http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-techno te-about-openssl-on-os-x -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 24.03.2014 18:23, Ned Deily wrote: In article cadisq7f0cnzrfm4i8xj13j+slq63uynqkdo12czm5yeq3bf...@mail.gmail.com, Nick Coghlan ncogh...@gmail.com wrote: You also reminded me that I need to dig around for and reference Ned's email about the status of OS X and reference that (OpenSSL upgrades were a casualty of Apple's anti-GPL crusade, so the OS X installers were switched to static linking somewhere along the line). AFAIK, Apple's decision to deprecate OpenSSL has nothing to do with the GPL, since OpenSSL isn't GPL-licensed, but rather with OpenSSL API compatibility issues: http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-techno te-about-openssl-on-os-x What a strange reasoning. Do they really believe that ABIs don't change when bumping the library version from 0.9.8 to 1.0.0 ? OpenSSL's history w/r to backwards compatibility up until 0.9.7 wasn't the greatest, but since 0.9.8 it has gotten to a level that's very reliable. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 24 2014) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-03-29: PythonCamp 2014, Cologne, Germany ... 5 days to go 2014-04-09: PyCon 2014, Montreal, Canada ... 16 days to go 2014-04-29: Python Meeting Duesseldorf ... 36 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
Nick Coghlan ncogh...@gmail.com writes: Maintainability --- This policy does NOT represent a commitment by volunteer contributors to actually backport network security related changes from the Python 3 series to the Python 2 series. Rather, it is intended to send a clear signal to potential corporate contributors that the core development team are willing to review and merge corporate contributions that put this policy into effect. As I understand, at least for smaller patches it is actually more work to apply a patch than than to write it. With that in mind, are there really sufficient volunteer resources available to review and merge these corporate contributions if they come? The issue tracker certainly does not lack issues with unreviewed and/or unapplied patches... Best, -Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 25 Mar 2014 04:00, Nikolaus Rath nikol...@rath.org wrote: Nick Coghlan ncogh...@gmail.com writes: Maintainability --- This policy does NOT represent a commitment by volunteer contributors to actually backport network security related changes from the Python 3 series to the Python 2 series. Rather, it is intended to send a clear signal to potential corporate contributors that the core development team are willing to review and merge corporate contributions that put this policy into effect. As I understand, at least for smaller patches it is actually more work to apply a patch than than to write it. With that in mind, are there really sufficient volunteer resources available to review and merge these corporate contributions if they come? The issue tracker certainly does not lack issues with unreviewed and/or unapplied patches... At least to start, this would likely be about seeking more upstream time for existing core contributors. Beyond that, PEP 462 covers another way for corporate users to give back - if they want to build massive commercial enterprises on our software, they can help maintain and upgrade the infrastructure that makes it possible in the first place. It's potentially worth reading some of the board candidate statements for this year, particularly mine and Van's: https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014 The lack of paid development time for CPython compared to similarly critical projects like the Linux kernel and OpenStack is of grave concern to me personally from a volunteer burnout perspective, and it was a problem at least Van and I were already specifically wanting to address over the next year or so. Over the course of writing the PEP I realised that the situation with the Python 2 network security modules is a perfect example of the kinds of problems that the current lack of upstream engagement and investment can cause. Cheers, Nick. Best, -Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Mar 24, 2014, at 5:38 PM, Nick Coghlan ncogh...@gmail.com wrote: On 25 Mar 2014 04:00, Nikolaus Rath nikol...@rath.org wrote: Nick Coghlan ncogh...@gmail.com writes: Maintainability --- This policy does NOT represent a commitment by volunteer contributors to actually backport network security related changes from the Python 3 series to the Python 2 series. Rather, it is intended to send a clear signal to potential corporate contributors that the core development team are willing to review and merge corporate contributions that put this policy into effect. As I understand, at least for smaller patches it is actually more work to apply a patch than than to write it. With that in mind, are there really sufficient volunteer resources available to review and merge these corporate contributions if they come? The issue tracker certainly does not lack issues with unreviewed and/or unapplied patches... At least to start, this would likely be about seeking more upstream time for existing core contributors. Beyond that, PEP 462 covers another way for corporate users to give back - if they want to build massive commercial enterprises on our software, they can help maintain and upgrade the infrastructure that makes it possible in the first place. It's potentially worth reading some of the board candidate statements for this year, particularly mine and Van's: https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014 The lack of paid development time for CPython compared to similarly critical projects like the Linux kernel and OpenStack is of grave concern to me personally from a volunteer burnout perspective, and it was a problem at least Van and I were already specifically wanting to address over the next year or so. Over the course of writing the PEP I realised that the situation with the Python 2 network security modules is a perfect example of the kinds of problems that the current lack of upstream engagement and investment can cause. Cheers, Nick. Best, -Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io I'd like to just go on a brief tangent here. While I totally agree that it would be incredibly awesome if more companies put dedicated time into developing and maintaining CPython I don't think pushing all the blame on to them is accurate. The attitude towards security issues and backwards compatibility has a somewhat equal share in the causes of the aging security infrastructure of the 2.x line. Now this PEP, if accepted, does a lot to resolve the largest offenders of this policy (and there has been some signs lately that perhaps going forward this will be better) but I think it is not doing anyone a favor if we just point fingers *over there* and claim the fault lies with someone else doing or not doing something. I *don't* want to disparage anyone or anything of that like, mostly to say that while of course increased resources from corporate users would help the situation immensely but that additionally there is a reasonably sized contingent of influential members who still want to treat Python as a hobbyist project and not a critical piece of the infrastructure of the Internet as a whole. I *don't* want to get help from downstream users, especially on important but boring or hard issues such as security, and then have them feel shutdown and unable to actually get anything done as others who have attempted to resolve some of these issues in the past have had happen to them. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 3/24/2014 7:04 PM, Donald Stufft wrote: On Mar 24, 2014, at 5:38 PM, Nick Coghlan ncogh...@gmail.com mailto:ncogh...@gmail.com wrote: Beyond that, PEP 462 covers another way for corporate users to give back - if they want to build massive commercial enterprises on our software, they can help maintain and upgrade the infrastructure that makes it possible in the first place. It's potentially worth reading some of the board candidate statements for this year, particularly mine and Van's: https://wiki.python.org/moin/PythonSoftwareFoundation/BoardCandidates2014 I read all of them. The lack of paid development time for CPython compared to similarly critical projects like the Linux kernel and OpenStack is of grave concern to me personally from a volunteer burnout perspective, I am glad to read that. Some of the expert professional core developers scoff at me being burned out from News Merge Hell and push race losses. and it was a problem at least Van and I were already specifically wanting to address over the next year or so. Over the course of writing the PEP I realised that the situation with the Python 2 network security modules is a perfect example of the kinds of problems that the current lack of upstream engagement and investment can cause. I'd like to just go on a brief tangent here. While I totally agree that it would be incredibly awesome if more companies put dedicated time into developing and maintaining CPython I don't think pushing all the blame on to them is accurate. For all I know, PSF has not yet asked in the right way, whatever that would be. will be better) but I think it is not doing anyone a favor if we just point fingers *over there* and claim the fault lies with someone else doing or not doing something. I agree that we should better figure out what to go going forward. I *don't* want to disparage anyone or anything of that like, mostly to say that while of course increased resources from corporate users would help the situation immensely but that additionally there is a reasonably sized contingent of influential members who still want to treat Python as a hobbyist project and not a critical piece of the infrastructure of the Internet as a whole. I find that surprising as I do not personally know any such people. To me, Python is both. My only objection is to corporatists who want to exclude amateur and hobbyist projects, for instance from PyPI (which I believe started as a hobbyist project). I personally would like someone paid full-time to upgrade the commit infrastructure, as soon possible. to make current committers more productive and make becoming a committer more attractive. Then I would like 2 people paid, one for doc issues, one to code, to work on the backlog of contributed patches. I know that are people who are not contributing any more because their previous contributions have sat unattended to. I *don't* want to get help from downstream users, especially on important but boring or hard issues such as security, and then have them feel shutdown and unable to actually get anything done as others who have attempted to resolve some of these issues in the past have had happen to them. Just from reading pydev, I am not familiar with such events and cannot comment. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
Several significant changes in this revision: - scope narrowed to just Python 2.7 plus permission for commercial redistributors to use the same strategy in their long term support releases - far more explicit that this is about inviting potential corporate contributors to address the situation for the benefit of the overall Python ecosystem, not offering to fix it for them for free - clarified that third party integration testing services would need to be updated to support testing against multiple Python 2.7 minor releases - explicit sections on why I don't think the status quo is sustainable, why I don't think Python 2.8 would actually solve the problem, and why I think a PyPI based solution not only wouldn't solve the problem, but would be rather difficult to get working in the first place - be completely explicit that I am *not* speaking on behalf of Red Hat at this point and have no authority to make commitments on their behalf. Instead, I'm looking for upstream consensus that 1) this is a genuine problem that needs to be solved; 2) we're open to corporate assistance in solving it; and 3) we have a pretty good idea what help we actually want. If all that happens, *then* I can take up the issue internally to try to get us some help in maintaining the proposed solution (hopefully other folks with corporate influence can do the same, and we may actually get some ongoing assistance with upstream maintenance out of this, rather than having our downstream redistributors continue to take us for granted). Diff: http://hg.python.org/peps/rev/2e82209dda21 Updated web version: http://www.python.org/dev/peps/pep-0466/ Advance warning: while I was able to get this revision turned around pretty quickly, future revisions are likely to take a fair bit longer. It was already a rather busy month before I decided to start this discussion on top of everything else :) Cheers, Nick. PEP: 466 Title: Network Security Enhancement Exception for Python 2.7 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan ncogh...@gmail.com, Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Mar-2014 Post-History: 23-Mar-2014 Abstract Most CPython tracker issues are classified as errors in behaviour or proposed enhancements. Most patches to fix behavioural errors are applied to all active maintenance branches. Enhancement patches are restricted to the default branch that becomes the next Python version. This cadence works reasonably well during Python's normal 18-24 month feature release cycle, which is still applicable to the Python 3 series. However, the age of the standard library in Python 2 has now reached a point where it is sufficiently far behind the state of the art in network security protocols for it to be causing real problems in commercial use cases where upgrading to Python 3 in the near term may not be practical. Accordingly, this PEP relaxes the normal restrictions by allowing enhancements to be applied in Python 2.7 maintenance releases for standard library components that have implications for the overall security of the internet. In particular, the exception will apply to: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module * the ``sha`` module (Python 2 only) * the components of other networking modules that make use of these modules * the components of the ``random`` and ``os`` modules that are relevant to cryptographic applications * the version of OpenSSL bundled with the binary installers Proposed backports for these modules will still need to undergo normal backwards compatibility assessments, but new features will be permitted where appropriate, making it easier to implement secure networked software in Python, even for software that needs to remain compatible with older feature releases of Python. While this PEP does not make any changes to the core development team's handling of security-fix-only branches that are no longer in active maintenance, it *does* recommend that commercial redistributors providing extended support periods for the Python standard library either adopt a similar approach to ensuring that the secure networking infrastructure keeps pace with the evolution of the internet, or else disclaim support for the use of older versions in roles that involving connecting directly to the public internet. Exemption Policy Under this policy, the following network security related modules are granted a blanket exemption to the restriction against adding new features in maintenance releases, for the purpose of keeping their APIs aligned with their counterparts in the latest feature release of Python 3: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module * the ``sha`` module (Python 2 only) This exemption applies to *all* proposals to backport backwards compatible changes in these modules to Python 2.7 maintenance releases. This choice is made deliberately to ensure that the feature or fix? argument
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Mar 23, 2014, at 3:07 AM, Nick Coghlan ncogh...@gmail.com wrote: Several significant changes in this revision: - scope narrowed to just Python 2.7 plus permission for commercial redistributors to use the same strategy in their long term support releases - far more explicit that this is about inviting potential corporate contributors to address the situation for the benefit of the overall Python ecosystem, not offering to fix it for them for free - clarified that third party integration testing services would need to be updated to support testing against multiple Python 2.7 minor releases For what it’s worth, I have an outstanding PR against Travis CI that would make this trivial for them at least. They are a pretty popular CI service especially for OSS projects. I made that PR for unrelated reasons but it could at least serve as a template for other projects to do the same thing. - explicit sections on why I don't think the status quo is sustainable, why I don't think Python 2.8 would actually solve the problem, and why I think a PyPI based solution not only wouldn't solve the problem, but would be rather difficult to get working in the first place - be completely explicit that I am *not* speaking on behalf of Red Hat at this point and have no authority to make commitments on their behalf. Instead, I'm looking for upstream consensus that 1) this is a genuine problem that needs to be solved; 2) we're open to corporate assistance in solving it; and 3) we have a pretty good idea what help we actually want. If all that happens, *then* I can take up the issue internally to try to get us some help in maintaining the proposed solution (hopefully other folks with corporate influence can do the same, and we may actually get some ongoing assistance with upstream maintenance out of this, rather than having our downstream redistributors continue to take us for granted). Diff: http://hg.python.org/peps/rev/2e82209dda21 Updated web version: http://www.python.org/dev/peps/pep-0466/ Advance warning: while I was able to get this revision turned around pretty quickly, future revisions are likely to take a fair bit longer. It was already a rather busy month before I decided to start this discussion on top of everything else :) Cheers, Nick. PEP: 466 Title: Network Security Enhancement Exception for Python 2.7 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan ncogh...@gmail.com, Status: Draft Type: Informational Content-Type: text/x-rst Created: 23-Mar-2014 Post-History: 23-Mar-2014 Abstract Most CPython tracker issues are classified as errors in behaviour or proposed enhancements. Most patches to fix behavioural errors are applied to all active maintenance branches. Enhancement patches are restricted to the default branch that becomes the next Python version. This cadence works reasonably well during Python's normal 18-24 month feature release cycle, which is still applicable to the Python 3 series. However, the age of the standard library in Python 2 has now reached a point where it is sufficiently far behind the state of the art in network security protocols for it to be causing real problems in commercial use cases where upgrading to Python 3 in the near term may not be practical. Accordingly, this PEP relaxes the normal restrictions by allowing enhancements to be applied in Python 2.7 maintenance releases for standard library components that have implications for the overall security of the internet. In particular, the exception will apply to: * the ``ssl`` module * the ``hashlib`` module * the ``hmac`` module * the ``sha`` module (Python 2 only) * the components of other networking modules that make use of these modules * the components of the ``random`` and ``os`` modules that are relevant to cryptographic applications * the version of OpenSSL bundled with the binary installers Proposed backports for these modules will still need to undergo normal backwards compatibility assessments, but new features will be permitted where appropriate, making it easier to implement secure networked software in Python, even for software that needs to remain compatible with older feature releases of Python. While this PEP does not make any changes to the core development team's handling of security-fix-only branches that are no longer in active maintenance, it *does* recommend that commercial redistributors providing extended support periods for the Python standard library either adopt a similar approach to ensuring that the secure networking infrastructure keeps pace with the evolution of the internet, or else disclaim support for the use of older versions in roles that involving connecting directly to the public internet. Exemption Policy Under this policy, the following network security related modules are granted a blanket exemption to the restriction against adding
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Sun, Mar 23, 2014 at 6:07 PM, Nick Coghlan ncogh...@gmail.com wrote: And that's just three of the highest profile open source projects that make heavy use of Python. Given the likely existence of large amounts of legacy code that lacks the kind of automated regression test suite needed to help support a migration from Python 2 to Python 3. The key point of this PEP is that those situations affect more people than just the developers and users of the affected application: their existence becomes something that developers of secure networked services need to take into account as part of their security design. Grammatical point: The sentence beginning Given... doesn't seem complete. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
Am 23.03.14 08:07, schrieb Nick Coghlan: Several significant changes in this revision: - scope narrowed to just Python 2.7 plus permission for commercial redistributors to use the same strategy in their long term support releases Thanks; the rationale is now much clearer, and also indicates yet another alternative path: fork Python. The PEP indicates that vendors are likely to fork Python anyway (as they always did, in a small scale). This could become more official and coordinated. Create an enhanced TLS clone of cpython, and start applying changes to 2.6, 2.7, and any other branches you consider relevant. Keep it merged with the cpython code base. This model has worked for many years for Stackless Python. Then, vendors have the choice of either releasing from the official CPython repository, or from the enhanced TLS one. All reasoning on application-level feature testing still applies: applications would have to feature-test whether they run on python.org release, or on an enhanced release. For Windows in particular, it would be up to ActiveState to decide whether they build binaries from python.org, or from the enhanced TLS repo. They could actually opt to provide both, leaving the choice to users. Even if this notion of forking is not acceptable, I suggest that you could still start working on the code in a separate clone, and the decision on the PEP could be deferred until a proposed implementation is ready. I see it as a risk of the PEP that the implementation might not be available before May 2015, in which case the PEP would become irrelevant. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 23 Mar 2014 18:42, Martin v. Löwis mar...@v.loewis.de wrote: Am 23.03.14 08:07, schrieb Nick Coghlan: Several significant changes in this revision: - scope narrowed to just Python 2.7 plus permission for commercial redistributors to use the same strategy in their long term support releases Thanks; the rationale is now much clearer, and also indicates yet another alternative path: fork Python. The PEP indicates that vendors are likely to fork Python anyway (as they always did, in a small scale). This could become more official and coordinated. Create an enhanced TLS clone of cpython, and start applying changes to 2.6, 2.7, and any other branches you consider relevant. Keep it merged with the cpython code base. This model has worked for many years for Stackless Python. Then, vendors have the choice of either releasing from the official CPython repository, or from the enhanced TLS one. All reasoning on application-level feature testing still applies: applications would have to feature-test whether they run on python.org release, or on an enhanced release. For Windows in particular, it would be up to ActiveState to decide whether they build binaries from python.org, or from the enhanced TLS repo. They could actually opt to provide both, leaving the choice to users. Even if this notion of forking is not acceptable, I suggest that you could still start working on the code in a separate clone, and the decision on the PEP could be deferred until a proposed implementation is ready. I see it as a risk of the PEP that the implementation might not be available before May 2015, in which case the PEP would become irrelevant. Yes, a 2.7-enhanced-tls clone is definitely a good notion. Your suggestion to recast the entire PEP along those lines, so we always retain the option of choosing between them, also sounds plausible. Cheers, Nick. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Sun, 23 Mar 2014 17:07:24 +1000 Nick Coghlan ncogh...@gmail.com wrote: Another more critical example is the lack of SSL hostname matching in the Python 2 standard library - it is currently necessary to rely on a third party library, such as ``requests`` or ``backports.ssl_match_hostname`` to obtain that functionality in Python 2. Do note that match_hostname() is a pure Python function and is easy to paste into your own code (if you don't want to pull in a dependency). It doesn't need SSLContext or any other recent stuff, just a certificate dict which Python 2.x is already able to provide (SSLSocket.getpeercert()). Firstly, this PEP encompasses a non-trivial portion of the standard library. It's not just the underlying SSL support, but also the libraries for other network protocols like HTTP, FTP, IMAP, and POP3 that integrate with the SSL infrastructure to provide secure links, and that's just the protocols in the standard library. It's still not obvious what you are proposing to do with these other libraries. If you are proposing to validate certs against system CAs and check hostnames by default - you are going to break compatibility for a lot of current uses. As Martin I think it would be easier to reason about a concrete backport proposal. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On 23 March 2014 07:07, Nick Coghlan ncogh...@gmail.com wrote: Advance warning: while I was able to get this revision turned around pretty quickly, future revisions are likely to take a fair bit longer. It was already a rather busy month before I decided to start this discussion on top of everything else :) Ha - you produced this update while I was still thinking about the first draft, and it arrived (unnoticed) while I was writing my response. Sorry if some or all of my points in the other email are now irrelevant as a result. I'll try to read and assess this version before responding - so feel free to take longer over the next revision:-) Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 466 (round 2): Network security enhancements for Python 2.7
On Mar 23, 2014, at 9:13 AM, Antoine Pitrou solip...@pitrou.net wrote: On Sun, 23 Mar 2014 17:07:24 +1000 Nick Coghlan ncogh...@gmail.com wrote: Another more critical example is the lack of SSL hostname matching in the Python 2 standard library - it is currently necessary to rely on a third party library, such as ``requests`` or ``backports.ssl_match_hostname`` to obtain that functionality in Python 2. Do note that match_hostname() is a pure Python function and is easy to paste into your own code (if you don't want to pull in a dependency). It doesn't need SSLContext or any other recent stuff, just a certificate dict which Python 2.x is already able to provide (SSLSocket.getpeercert()). So the problem with match_hostname is that it’s a security sensitive function, there have already been at least one fix to it because of it doing something incorrectly. Advocating users to copy it into their own code case typically means that it’ll get copied once and forgotten. So for any security updates in the future they are unlikely to get those. It seems like the danger of _adding_ things like that is pretty minimal. Firstly, this PEP encompasses a non-trivial portion of the standard library. It's not just the underlying SSL support, but also the libraries for other network protocols like HTTP, FTP, IMAP, and POP3 that integrate with the SSL infrastructure to provide secure links, and that's just the protocols in the standard library. It's still not obvious what you are proposing to do with these other libraries. If you are proposing to validate certs against system CAs and check hostnames by default - you are going to break compatibility for a lot of current uses. As Martin I think it would be easier to reason about a concrete backport proposal. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
