[Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?
Serhiy Storchaka
storchaka at gmail.com
Tue Nov 7 17:27:32 EST 2017
More information about the Python-ideas mailing list
Tue Nov 7 17:27:32 EST 2017
- Previous message (by thread): [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?
- Next message (by thread): [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
07.11.17 16:41, Steven D'Aprano пише: > On Tue, Nov 07, 2017 at 03:35:58PM +0200, Serhiy Storchaka wrote: >> 07.11.17 12:29, אלעזר пише: >>> Also, it is unfortunate that `ast.literal_eval` is less accessible than >>> `builtins.eval`. Giving it an alias in builtins might make it easier for >>> programmers (and less scary - "ast" might sound like I need a PhD to use >>> it). >> >> ast.literal_eval is not so safe as you think. Malicious input can cause >> a stack overflow in your program. [1] >> >> [1] https://bugs.python.org/issue31113 > > > I don't see anything about literal_eval in that bug report. Sorry, this particular issue isn't related to literal_eval. There was other recently fixed issue, but I forgot its number. But the point is that the compiler is recursive, and processing nested constructs consumes the C stack. There are some guards against too deep recursion (2.7 has less guards and more vulnerable), but it is hard to prove that all vulnerabilities are fixed. Your method (limiting the size of the input) helps against some attacks. Other methods -- restricting the set of characters and the number of parenthesis, braces and brackets.
- Previous message (by thread): [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?
- Next message (by thread): [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list