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
forked frompython/cpython

Commit8baef8a

Browse files
authored
pythongh-95588: Drop the safety claim fromast.literal_eval docs. (python#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.
1 parentbd7d0e8 commit8baef8a

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
@@ -1991,20 +1991,28 @@ and classes for traversing abstract syntax trees:
19911991

19921992
..function::literal_eval(node_or_string)
19931993

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

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

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

20092017
It can raise:exc:`ValueError`,:exc:`TypeError`,:exc:`SyntaxError`,
20102018
: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
@@ -54,10 +54,12 @@ def parse(source, filename='<unknown>', mode='exec', *,
5454

5555
defliteral_eval(node_or_string):
5656
"""
57-
Safely evaluatean expression node or a string containing a Python
57+
Evaluatean expression node or a string containing only a Python
5858
expression. The string or node provided may only consist of the following
5959
Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
6060
sets, booleans, and None.
61+
62+
Caution: A complex expression can overflow the C stack and cause a crash.
6163
"""
6264
ifisinstance(node_or_string,str):
6365
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