Skip to content

Commit a4fbb94

Browse files
gh-95588: Drop the safety claim from ast.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 commit 8baef8a) Co-authored-by: Gregory P. Smith <greg@krypto.org>
1 parent 748b2b7 commit a4fbb94

File tree

3 files changed

+25
-9
lines changed

3 files changed

+25
-9
lines changed

Doc/library/ast.rst

+16-8
Original file line numberDiff line numberDiff line change
@@ -1959,20 +1959,28 @@ and classes for traversing abstract syntax trees:
19591959

19601960
.. function:: literal_eval(node_or_string)
19611961

1962-
Safely evaluate an expression node or a string containing a Python literal or
1962+
Evaluate an expression node or a string containing only a Python literal or
19631963
container display. The string or node provided may only consist of the
19641964
following Python literal structures: strings, bytes, numbers, tuples, lists,
19651965
dicts, sets, booleans, ``None`` and ``Ellipsis``.
19661966

1967-
This can be used for safely evaluating strings containing Python values from
1968-
untrusted sources without the need to parse the values oneself. It is not
1969-
capable of evaluating arbitrarily complex expressions, for example involving
1970-
operators or indexing.
1967+
This can be used for evaluating strings containing Python values without the
1968+
need to parse the values oneself. It is not capable of evaluating
1969+
arbitrarily complex expressions, for example involving operators or
1970+
indexing.
1971+
1972+
This function had been documented as "safe" in the past without defining
1973+
what that meant. That was misleading. This is specifically designed not to
1974+
execute Python code, unlike the more general :func:`eval`. There is no
1975+
namespace, no name lookups, or ability to call out. But it is not free from
1976+
attack: A relatively small input can lead to memory exhaustion or to C stack
1977+
exhaustion, crashing the process. There is also the possibility for
1978+
excessive CPU consumption denial of service on some inputs. Calling it on
1979+
untrusted data is thus not recommended.
19711980

19721981
.. warning::
1973-
It is possible to crash the Python interpreter with a
1974-
sufficiently large/complex string due to stack depth limitations
1975-
in Python's AST compiler.
1982+
It is possible to crash the Python interpreter due to stack depth
1983+
limitations in Python's AST compiler.
19761984

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

Lib/ast.py

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

5454
def literal_eval(node_or_string):
5555
"""
56-
Safely evaluate an expression node or a string containing a Python
56+
Evaluate an 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
if isinstance(node_or_string, str):
6264
node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
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)