Jan Lieskovsky <ian...@seznam.cz> added the comment: Antoine,
(re: #msg87083, #msg87084) -- while the API change is acceptable and reasonable, it doesn't solve the core of the problem. I understand the change needs to be 'backward compatible' and shouldn't break the existing Python behavior, but the current proposed patch: 1, doesn't avoid the need to fix the issue (by calling "PySys_SetArgvEx(argc, argv, 0);") in all current applications embedding Python, 2, doesn't dismiss the risk of future appearance of application, embedding Python interpreter and using it in a vulnerable way (in fact, all what it does, is adding recommendation / alternative to use more safer PySys_SetArgv(*, *, 0) for such cases. I don't think we can just rely on the fact, the developers will use it in a safe way in the future -- or did I overlooked something? Wouldn't be possible to fix it 'only in Python' and prevent such potential future malicious (mis)uses? To Martin (re: #msg87212): What's the question of 'security nature' of the issue, Glyph in message #msg86927 already uncovered potential implications -- if the application was written either 'by accident', or 'by intention', it shouldn't just allow to execute anything with the privileges of superuser, and even worse, doing it silently (then the only warranty for the unprivileged user would be to rely on the fact, the function was called 'in a safe way' in the application and I suppose such assumption would completely discourage him from running it). I recommend the final fix should be applied to all active Python branches (just comment on second part of Martin's comment). Regards, Jan. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5753> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
