Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit9189cd6

Browse files
gh-95588: Drop the safety claim fromast.literal_eval docs. (GH-95919)
It was never really safe and this claim conflicts directly with the big warning in the docs about it being able to crash the interpreter.(cherry picked from commit8baef8a)Co-authored-by: Gregory P. Smith <greg@krypto.org>
1 parent35a394c commit9189cd6

File tree

3 files changed

+25
-9
lines changed

3 files changed

+25
-9
lines changed

‎Doc/library/ast.rst‎

Lines changed: 16 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1990,20 +1990,28 @@ and classes for traversing abstract syntax trees:
19901990

19911991
..function::literal_eval(node_or_string)
19921992

1993-
Safely evaluatean expression node or a string containing a Python literal or
1993+
Evaluatean expression node or a string containing only a Python literal or
19941994
container display. The string or node provided may only consist of the
19951995
following Python literal structures: strings, bytes, numbers, tuples, lists,
19961996
dicts, sets, booleans, ``None`` and ``Ellipsis``.
19971997

1998-
This can be used for safely evaluating strings containing Python values from
1999-
untrusted sources without the need to parse the values oneself. It is not
2000-
capable of evaluating arbitrarily complex expressions, for example involving
2001-
operators or indexing.
1998+
This can be used for evaluating strings containing Python values without the
1999+
need to parse the values oneself. It is not capable of evaluating
2000+
arbitrarily complex expressions, for example involving operators or
2001+
indexing.
2002+
2003+
This function had been documented as "safe" in the past without defining
2004+
what that meant. That was misleading. This is specifically designed not to
2005+
execute Python code, unlike the more general:func:`eval`. There is no
2006+
namespace, no name lookups, or ability to call out. But it is not free from
2007+
attack: A relatively small input can lead to memory exhaustion or to C stack
2008+
exhaustion, crashing the process. There is also the possibility for
2009+
excessive CPU consumption denial of service on some inputs. Calling it on
2010+
untrusted data is thus not recommended.
20022011

20032012
..warning::
2004-
It is possible to crash the Python interpreter with a
2005-
sufficiently large/complex string due to stack depth limitations
2006-
in Python's AST compiler.
2013+
It is possible to crash the Python interpreter due to stack depth
2014+
limitations in Python's AST compiler.
20072015

20082016
It can raise:exc:`ValueError`,:exc:`TypeError`,:exc:`SyntaxError`,
20092017
:exc:`MemoryError` and:exc:`RecursionError` depending on the malformed

‎Lib/ast.py‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -53,10 +53,12 @@ def parse(source, filename='<unknown>', mode='exec', *,
5353

5454
defliteral_eval(node_or_string):
5555
"""
56-
Safely evaluatean expression node or a string containing a Python
56+
Evaluatean expression node or a string containing only a Python
5757
expression. The string or node provided may only consist of the following
5858
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
5959
sets, booleans, and None.
60+
61+
Caution: A complex expression can overflow the C stack and cause a crash.
6062
"""
6163
ifisinstance(node_or_string,str):
6264
node_or_string=parse(node_or_string.lstrip("\t"),mode='eval')
Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
Clarified the conflicting advice given in the:mod:`ast` documentation about
2+
:func:`ast.literal_eval` being "safe" for use on untrusted input while at
3+
the same time warning that it can crash the process. The latter statement is
4+
true and is deemed unfixable without a large amount of work unsuitable for a
5+
bugfix. So we keep the warning and no longer claim that ``literal_eval`` is
6+
safe.

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp