Mailman 3 December 2014 - docs

[issue22988] No error when yielding from `finally`
by Ethan Furman 03 Dec '14

03 Dec '14

Ethan Furman added the comment: Here's the excerpt from the docs: -------------------------------- > Yield expressions are allowed in the try clause of a try ... finally construct. > If the generator is not resumed before it is finalized (by reaching a zero reference > count or by being garbage collected), the generator-iterator’s close() method will be > called, allowing any pending finally clauses to execute. This certainly makes it sound like 'yield' is okay in the 'try' portion, but not the 'finally' portion. So 'yield' is allowed in the 'try' portion, and it's allowed in the 'finally' portion -- is it also allowed in the 'except' portion? If so, we could simplify the first line to: > Yield expressions are allowed in try ... except ... finally constructs. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22988> _______________________________________

1 0

[issue22988] No error when yielding from `finally`
by R. David Murray 03 Dec '14

03 Dec '14

R. David Murray added the comment: FIlipe, in case you hadn't noticed, the reason for the error in the other issue is that the generator was closed when it got garbage collected, and it ignored the close (executed a yield after the close). Thus the error message there is accurate and expected, just as (as Guido said) the behavior here is consistent with the combined semantics of generators and try/finally. Do you want to suggest an improvement to the docs? It may be that we'll decide a change is more confusing than helpful, but we'll need someone to suggest a wording to decide that. ---------- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python, r.david.murray versions: +Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22988> _______________________________________

1 0

Re: [docs] os.popen & os.system lack shell-related security warnings (issue 21557)
by demianbrecht＠gmail.com 03 Dec '14

03 Dec '14

I stand corrected, the patched docs do look good and are consistent with the warning in "Frequently Used Arguments" section in the subprocess module docs. Just a minor point about linking to subprocess.Popen rather than the subprocess module. http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst File Doc/library/os.rst (right): http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst#newcode29… Doc/library/os.rst:2905: .. warning:: Fair points. I also hadn't previously seen the warning in the frequently used arguments section (https://docs.python.org/2/library/subprocess.html#frequently-used-arguments) and do like that this is consistent with it. http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst#newcode29… Doc/library/os.rst:2913: For greater safety, consider using :mod:`subprocess` with This should point to subprocess.Popen (https://docs.python.org/2/library/subprocess.html#subprocess.Popen) rather than the module, no? http://bugs.python.org/review/21557/

1 0

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
by Serhiy Storchaka 03 Dec '14

03 Dec '14

Serhiy Storchaka added the comment: Arfrever have suggested on IRC to backport documentation part of the patch to 3.4. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17401> _______________________________________

1 0

Re: [docs] os.popen & os.system lack shell-related security warnings (issue 21557)
by pybugs＠rebertia.com 02 Dec '14

02 Dec '14

Reviewers: demian, http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst File Doc/library/os.rst (right): http://bugs.python.org/review/21557/diff/13339/Doc/library/os.rst#newcode29… Doc/library/os.rst:2905: .. warning:: On 2014/12/01 23:46:04, demian wrote: > This warning is a little confusing to me. If input sanitization is the issue > (which is a perfectly valid concern), why not explain the issue and how to plug > the hole rather than discouraging its use altogether? > > As is, this reads a little strange to me given you're discouraging the use due > to a specific case and then in the next paragraph explaining how to fix it. I'd > rather just see an explanation of the possible security hole and how to account > for it to make the usage here safe. A. The patch doesn't discourage it altogether, it discourages it specifically "in cases where the command string is constructed from external input". B. os.popen() deserves to be discouraged. It *defaults to being insecure* and you must specifically remember to actively do the escaping yourself every time. This makes it usage pretty error-prone. History has shown that it's all too easy to overlook the need to do escaping. The subprocess module (when shell=False, which is by default) is not error-prone in this way, and is thus superior. subprocess is also more flexible and featureful. I know of no countervailing advantages whatsoever to using os.popen(). Users often do not need / do not make use of shell features in their commands. IMO, there's currently no good reason to ever use os.popen() instead of the subprocess module. Legacy code is the only reason to still be using it. Please review this at http://bugs.python.org/review/21557/ Affected files: Doc/library/os.rst diff -r 62a058c76869 Doc/library/os.rst --- a/Doc/library/os.rst Mon Dec 01 13:10:12 2014 +0200 +++ b/Doc/library/os.rst Mon Dec 01 12:15:45 2014 -0800 @@ -2899,8 +2899,23 @@ contains the signed integer return code from the child process. This is implemented using :class:`subprocess.Popen`; see that class's - documentation for more powerful ways to manage and communicate with - subprocesses. + documentation for safer and more powerful ways to manage and communicate + with subprocesses. + + .. warning:: + + The use of :func:`popen` is **strongly discouraged** in cases where the + command string is constructed from external input. Executing shell + commands that incorporate unsanitized input from an untrusted source + makes a program vulnerable to `shell injection + <http://en.wikipedia.org/wiki/Shell_injection#Shell_injection>`_, + a serious security flaw which can result in arbitrary command execution. + For greater safety, consider using :mod:`subprocess` with + ``shell=False`` instead. + + :func:`shlex.quote` can be used to properly escape whitespace and shell + metacharacters in strings that are going to be used to construct shell + commands. .. function:: spawnl(mode, path, ...) @@ -3046,10 +3061,25 @@ status of the command run; on systems using a non-native shell, consult your shell documentation. - The :mod:`subprocess` module provides more powerful facilities for spawning - new processes and retrieving their results; using that module is preferable - to using this function. See the :ref:`subprocess-replacements` section in - the :mod:`subprocess` documentation for some helpful recipes. + The :mod:`subprocess` module provides safer and more powerful facilities + for spawning new processes and retrieving their results; using that module + is preferable to using this function. See the :ref:`subprocess-replacements` + section in the :mod:`subprocess` documentation for some helpful recipes. + + .. warning:: + + The use of :func:`system` is **strongly discouraged** in cases where the + command string is constructed from external input. Executing shell + commands that incorporate unsanitized input from an untrusted source + makes a program vulnerable to `shell injection + <http://en.wikipedia.org/wiki/Shell_injection#Shell_injection>`_, + a serious security flaw which can result in arbitrary command execution. + For greater safety, consider using :mod:`subprocess` with + ``shell=False`` instead. + + :func:`shlex.quote` can be used to properly escape whitespace and shell + metacharacters in strings that are going to be used to construct shell + commands. Availability: Unix, Windows.

1 0

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
by Serhiy Storchaka 02 Dec '14

02 Dec '14

Changes by Serhiy Storchaka <storchaka(a)gmail.com>: ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17401> _______________________________________

1 0

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
by Serhiy Storchaka 02 Dec '14

02 Dec '14

Serhiy Storchaka added the comment: Committed the first patch (showing closefd always) with additional test from second path. ---------- versions: -Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17401> _______________________________________

1 0

[issue17401] io.FileIO closefd parameter is not documented nor shown in repr
by Roundup Robot 02 Dec '14

02 Dec '14

Roundup Robot added the comment: New changeset fd80195b920f by Serhiy Storchaka in branch 'default': Issue #17401: Output the closefd attribute as boolean. https://hg.python.org/cpython/rev/fd80195b920f ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17401> _______________________________________

1 0

[issue22475] asyncio task get_stack documentation seems to contradict itself
by R. David Murray 02 Dec '14

02 Dec '14

New submission from R. David Murray: The get_stack method docs say: "If the coroutine is active, returns the stack where it was suspended." I presume this means something more like "if the coroutine is not done...", since in English you can't be both active *and* suspended. Or does it mean "last suspended"? Then it talks about limit and how stacks limit returns newest frames while with tracebacks it is oldest frames...but the last sentence says that for suspended coroutines only one frame is returned. So there is a definite lack of clarity here: can we get multiple frames if the coroutine is not suspended (in which case that first sentence seems likely to be the 'last suspended' interpretation), or for non-tracebacks can we only ever get one frame, in which case why talk about limit returning the newest frames for stacks? ---------- assignee: docs@python components: Documentation messages: 227401 nosy: docs@python, r.david.murray priority: normal severity: normal status: open title: asyncio task get_stack documentation seems to contradict itself type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22475> _______________________________________

4 4

[issue22473] The gloss on asyncio "future with run_forever" example is confusing
by R. David Murray 02 Dec '14

02 Dec '14

New submission from R. David Murray: In https://docs.python.org/3/library/asyncio-task.html#example-future-with-run… we have the sentence In this example, the future is responsible to display the result and to stop the loop. We could dune up the English by rewriting it: In this example, the future is responsible for displaying the result and stopping the loop. But that isn't quite true. It is the callback associated with the future that is displaying the result and stopping the loop. So, perhaps the correct gloss is: In this example, the got_result callback is responsible for displaying the result and stopping the loop. ---------- assignee: docs@python components: Documentation messages: 227398 nosy: docs@python, r.david.murray priority: normal severity: normal status: open title: The gloss on asyncio "future with run_forever" example is confusing type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22473> _______________________________________

4 5

docs December 2014