[issue5088] optparse: inconsistent default value for append actions
Louis Deflandre added the comment: Hello, Tell me if the issue is too old to deserve comments anymore. But I would like to challenge the conclusion made in this issue. The message msg9944 stated "Think of the default as the initial list" but it is inconsistent with the proper meaning of default which can be defined as : "a preselected option adopted by a computer program or other mechanism WHEN NO ALTERNATIVE IS SPECIFIED" (http://www.wordreference.com/definition/default - Oxford Dictionary). The "initial list" conclusion seems to me more implementation oriented than really user oriented -- nosy: +louis.deflandre ___ Python tracker <http://bugs.python.org/issue5088> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
New submission from David Jean Louis : Hi, I'm the author of the polib python module, incidentally (after a bug report in polib: https://bitbucket.org/izi/polib/issue/27/polib-doesnt-check-unescaped-quote) I've found that the eval() in Tools/i18n/msgfmt.py allows arbitrary code execution, someone could create a malicious po entry like this: msgid "owned!" msgstr "" or __import__("os").popen("rm -rf /") As this is an "internal tool" used by developers, maybe it is not very important, but given that people may reuse this script for generating mo files, I think this needs to be fixed, I'm adding a patch for this issue. Regards, -- David -- components: Demos and Tools files: msgfmt.py.diff keywords: patch messages: 146678 nosy: izi priority: normal severity: normal status: open title: the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files type: security versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23566/msgfmt.py.diff ___ Python tracker <http://bugs.python.org/issue13301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
David Jean Louis added the comment: I'm adding an updated patch that also handles unescaped double quote at the beginning of the string. -- versions: +Python 2.6, Python 3.1, Python 3.4 Added file: http://bugs.python.org/file23567/msgfmt.py.diff.update1.diff ___ Python tracker <http://bugs.python.org/issue13301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
David Jean Louis added the comment: Hmm, I missed your previous message, indeed, unescaping is not handled by this patch, sorry about that. Here's how it is handled in polib: https://bitbucket.org/izi/polib/src/dbafdc621bf4/polib.py#cl-206 -- ___ Python tracker <http://bugs.python.org/issue13301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4216] subprocess.Popen hangs at communicate() when child exits
Louis-Dominique Dubeau <[EMAIL PROTECTED]> added the comment: I'm running python 2.5.2 on Ubuntu 8.10. I believe I've also encountered the problem reported here. The scenario in my case was the following: 1. Python process A uses subprocess.Popen to create another python process (B). Process B is created with stdout=PIPE and stderr=PIPE. Process A communicates with process B using communicate(). 2. Python process B, starts a ssh process (process C) which is invoked to open a new control socket in master mode. Process C is started without pipes so it gets its std{in,out,err} from process B. Process C is going to run for a long time. That is, it will run until a command is sent to the control socket to close the ssh connexion. 3. Process B does not wait for process C to end, so it ends right away. 4. Python process A remains stuck in communicate() until process C (ssh) dies even though process B has ended already. Analysis: The reason for this is that process C (ssh) gets its stdout and stderr from process B. But process C keeps both stdout and stderr opened until it is terminated. So process A does not get an EOF on the pipes it opened for communicating with process B until process C ends. The set of conditions which will trigger the effect is not outlandish. However, it is specific enough that testing by executing "pwd" or "ls -l", or "echo blah" or any other simple command won't trigger it. In my case, I fixed the problem by changing the code of process B to invoke process C with stdout and stderr set to PIPE and close those pipes as soon as process B is satisfied that process C is started properly. In this way, process A does not block. (FYI, process A in my case is the python testing tool nosetests. I use nosetests to test a backup script written in python and that script invokes ssh.) It seems that in general subprocess creators might have two needs: 1. Create a subprocess and communicate with it until there is no more data to be passed to its stdin or data to be read from its std{out,err}. 2. Create a subprocess and communicate with it *only* until *this* process dies. After it is dead, neither stdout nor stderr are of any interest. Currently, need 1 is addressed by communicate() but not need 2. In my scenario above, I was able to work around the problem by modifying process B but there are going to be cases where process B is not modifiable (or at least not easily modifiable). In those cases, process A has to be able to handle it. -- nosy: +lemur ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com