[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
