Adding a new C API function in 2.6
Hello, I would like to check that it's possible to a new C API function in the 2.6 branch, on the basis that it would help solve what seems to be reported as a security problem by several vendors (including Linux distributions) -- see http://bugs.python.org/issue5753 for a thorough discussion. The change is rather minimal at the code level; it adds a new function PySys_SetArgvEx which has an additional flag telling it whether to update sys.path or not. The existing PySys_SetArgv function unconditionally updates sys.path, which can allow shadowing of stdlib or third-party library modules by an attacker. Thank you Antoine.
Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version >= 2.6.6. --Guido On Thu, May 20, 2010 at 12:32 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hello,
I would like to check that it's possible to a new C API function in the 2.6 branch, on the basis that it would help solve what seems to be reported as a security problem by several vendors (including Linux distributions) -- see http://bugs.python.org/issue5753 for a thorough discussion.
The change is rather minimal at the code level; it adds a new function PySys_SetArgvEx which has an additional flag telling it whether to update sys.path or not. The existing PySys_SetArgv function unconditionally updates sys.path, which can allow shadowing of stdlib or third-party library modules by an attacker.
Thank you
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On May 20, 2010, at 12:53 PM, Guido van Rossum wrote:
Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version >= 2.6.6.
I concur, as long as the new API availability is clearly spelled out in the release notes, NEWS, and C API documentation. Maybe even provide an example #ifdef in the latter. Should we start thinking about releasing 2.6.6 soonish? -Barry
On 5/20/2010 5:52 PM, Barry Warsaw wrote:
On May 20, 2010, at 12:53 PM, Guido van Rossum wrote:
Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version>= 2.6.6.
I concur, as long as the new API availability is clearly spelled out in the release notes, NEWS, and C API documentation. Maybe even provide an example #ifdef in the latter.
Should we start thinking about releasing 2.6.6 soonish?
By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches).
On May 20, 2010, at 06:01 PM, Terry Reedy wrote:
On 5/20/2010 5:52 PM, Barry Warsaw wrote:
On May 20, 2010, at 12:53 PM, Guido van Rossum wrote:
Sounds good to me, since this is (a) a security fix that will make some vendors happy, and (b) only a C-level API. I expect that some apps embedding Python will use this API unconditionally and this break with earlier Python versions; this could be intentional because of the vulnerability (else why would they change their code to call the new API), or they can use an #if to check for a version>= 2.6.6.
I concur, as long as the new API availability is clearly spelled out in the release notes, NEWS, and C API documentation. Maybe even provide an example #ifdef in the latter.
Should we start thinking about releasing 2.6.6 soonish?
By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches).
I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release? -Barry
Should we start thinking about releasing 2.6.6 soonish?
By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches).
I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release?
Because it's a security fix? No. This issue has been sitting in the tracker for more than a year now, so it's not really relevant (IMO) whether the bug fix arrives two weeks earlier. Regards, Martin
On May 21, 2010, at 01:05 AM, Martin v. Löwis wrote:
Should we start thinking about releasing 2.6.6 soonish?
By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches).
I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release?
Because it's a security fix? No. This issue has been sitting in the tracker for more than a year now, so it's not really relevant (IMO) whether the bug fix arrives two weeks earlier.
Partly that, yes. But also, 2.7 final is not scheduled until July, so we could fit one more release in I think. If there's no clamor for it, I'm also happy to just wait for 2.6.6 until after Python 2.7 is released. -Barry
participants (5)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Guido van Rossum -
Terry Reedy