gh-95588: Drop the safety claim from ast.literal_eval docs.
#95919
Conversation
It was never safe and this claim conflicts directly with the big warning in the docs about it being able to crash the interpreter.
gpshead
added
docs
gpshead
requested review from
vstinner and
isidentical
and removed request for
isidentical
|
Can we state clearly that maliciously large/complex inputs can cause a DoS (process crash or slow execution time), but nothing worse than that? That's a useful guarantee, and not the same as what most people think of when they think "unsafe for untrusted input". (Can it even cause unbounded execution time? with the new parser, shouldn't |
|
It only takes 200 bytes to crash the process so it isn't even about being what I'd call large. (which is why i removed the word "large" from the warning) |
|
i'm weary of guaranteeing it doesn't lead to arbitrary code execution. I believe that is the intent and might be true, and any example that allowed that is one we'd care about, but it is hard to claim as the code this uses for parsing wasn't designed with untrusted input in mind because of the rhetorical "who even does that to a compiler?" question. so the wording i have here tries to explain that it isn't an arbitrary python code execution function. but doesn't specifically say it cannot lead to other things, just that we know you can get memory exhaustion and C stack overflows. |
|
unbounded time is possible but i can't get into the details of that in public right now. at input sizes too small to cause a stack overflow I do not believe you'll run into time issues. |
gpshead
removed
type-crash
|
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11. |
|
GH-97714 is a backport of this pull request to the 3.11 branch. |
|
GH-97715 is a backport of this pull request to the 3.10 branch. |
…ythonGH-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>
…ythonGH-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>
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>
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>
…ython#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.
* main: (2069 commits) pythongh-96512: Move int_max_str_digits setting to PyConfig (python#96944) pythongh-94808: Coverage: Check picklablability of calliter (python#95923) pythongh-94808: Add test coverage for PyObject_HasAttrString (python#96627) pythongh-94732: Fix KeyboardInterrupt race in asyncio run_forever() (python#97765) Fix typos in `bltinmodule.c`. (pythonGH-97766) pythongh-94808: `_PyLineTable_StartsLine` was not used (pythonGH-96609) pythongh-97681: Remove Tools/demo/ directory (python#97682) Fix typo in unittest docs (python#97742) pythongh-97728: Argument Clinic: Fix uninitialized variable in the Py_UNICODE converter (pythonGH-97729) pythongh-95913: Fix PEP number in PEP 678 What's New ref label (python#97739) pythongh-95913: Copyedit/improve New Modules What's New section (python#97721) pythongh-97740: Fix bang in Sphinx C domain ref target syntax (python#97741) pythongh-96819: multiprocessing.resource_tracker: check if length of pipe write <= 512 (python#96890) pythongh-97706: multiprocessing tests: Delete unused variable `rand` (python#97707) pythonGH-85447: Clarify docs about awaiting future multiple times (python#97738) [docs] Update logging cookbook with recipe for using a logger like an output… (pythonGH-97730) pythongh-97607: Fix content parsing in the impl-detail reST directive (python#97652) pythongh-95975: Move except/*/finally ref labels to more precise locations (python#95976) pythongh-97591: In `Exception.__setstate__()` acquire strong references before calling `tp_hash` slot (python#97700) pythongh-95588: Drop the safety claim from `ast.literal_eval` docs. (python#95919) ...
It was never safe and this claim conflicts directly with the big warning in the docs about it being able to crash the interpreter.
Making it safe is not a mere bugfix but an entire rewrite, we're never going to live up to the safety claim via a bugfix and people with existing releases will always have versions around that are unsafe even if we did. So making that claim is bad for our users.