-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
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. |
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 <[email protected]>
…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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
…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) ...
Lets try to backport this on 3.9 (see #126711). |
Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9. |
…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 <[email protected]>
GH-126729 is a backport of this pull request to the 3.9 branch. |
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.