]> git.ipfire.org Git - thirdparty/Python/cpython.git/commitdiff
[3.9] gh-95588: Drop the safety claim from `ast.literal_eval` docs. (GH-95919) (GH...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Tue, 3 Dec 2024 16:08:42 +0000 (17:08 +0100)
committerGitHub <noreply@github.com>
Tue, 3 Dec 2024 16:08:42 +0000 (17:08 +0100)
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 8baef8ae367041a5cfefb40b19c7b87e9bcb56a2)

Co-authored-by: Gregory P. Smith <greg@krypto.org>
Doc/library/ast.rst
Lib/ast.py
Misc/NEWS.d/next/Documentation/2022-08-12-01-12-52.gh-issue-95588.PA0FI7.rst [new file with mode: 0644]

index 149179d5bfd5d695555af464aff58925ee1893f3..1a77ee9879a4fa0bdda431c0aba226931455c3e7 100644 (file)
@@ -1591,20 +1591,28 @@ and classes for traversing abstract syntax trees:
 
 .. function:: literal_eval(node_or_string)
 
-   Safely evaluate an expression node or a string containing a Python literal or
+   Evaluate an expression node or a string containing only a Python literal or
    container display.  The string or node provided may only consist of the
    following Python literal structures: strings, bytes, numbers, tuples, lists,
    dicts, sets, booleans, and ``None``.
 
-   This can be used for safely evaluating strings containing Python values from
-   untrusted sources without the need to parse the values oneself.  It is not
-   capable of evaluating arbitrarily complex expressions, for example involving
-   operators or indexing.
+   This can be used for evaluating strings containing Python values without the
+   need to parse the values oneself.  It is not capable of evaluating
+   arbitrarily complex expressions, for example involving operators or
+   indexing.
+
+   This function had been documented as "safe" in the past without defining
+   what that meant. That was misleading. This is specifically designed not to
+   execute Python code, unlike the more general :func:`eval`. There is no
+   namespace, no name lookups, or ability to call out. But it is not free from
+   attack: A relatively small input can lead to memory exhaustion or to C stack
+   exhaustion, crashing the process. There is also the possibility for
+   excessive CPU consumption denial of service on some inputs. Calling it on
+   untrusted data is thus not recommended.
 
    .. warning::
-      It is possible to crash the Python interpreter with a
-      sufficiently large/complex string due to stack depth limitations
-      in Python's AST compiler.
+      It is possible to crash the Python interpreter due to stack depth
+      limitations in Python's AST compiler.
 
    .. versionchanged:: 3.2
       Now allows bytes and set literals.
index 396eea18303ceb0e69d29d5282a34d11a53b697a..19dcad477e72de25ef642a913c032b4ac9997b16 100644 (file)
@@ -53,10 +53,12 @@ def parse(source, filename='<unknown>', mode='exec', *,
 
 def literal_eval(node_or_string):
     """
-    Safely evaluate an expression node or a string containing a Python
+    Evaluate an expression node or a string containing only a Python
     expression.  The string or node provided may only consist of the following
     Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
     sets, booleans, and None.
+
+    Caution: A complex expression can overflow the C stack and cause a crash.
     """
     if isinstance(node_or_string, str):
         node_or_string = parse(node_or_string, mode='eval')
diff --git a/Misc/NEWS.d/next/Documentation/2022-08-12-01-12-52.gh-issue-95588.PA0FI7.rst b/Misc/NEWS.d/next/Documentation/2022-08-12-01-12-52.gh-issue-95588.PA0FI7.rst
new file mode 100644 (file)
index 0000000..c070bbc
--- /dev/null
@@ -0,0 +1,6 @@
+Clarified the conflicting advice given in the :mod:`ast` documentation about
+:func:`ast.literal_eval` being "safe" for use on untrusted input while at
+the same time warning that it can crash the process. The latter statement is
+true and is deemed unfixable without a large amount of work unsuitable for a
+bugfix. So we keep the warning and no longer claim that ``literal_eval`` is
+safe.