Is your feature request related to a problem? Please describe.
It is possible to crash the Python interpreter by passing sufficiently large/complex string to ast.literal_eval, ast.parse, compile, dbm.dumb.open, eval or exec due to stack depth limitations in Python’s AST compiler.
My biggest issue is with ast.literal_eval which is recommended as a safe(r) alternative to eval by both the official documentation and bandit itself, so I suspect it is commonly[citation needed] used for parsing untrusted data where some evaluation is needed, instead of using eval, which might cause a false sense of security.
Describe the solution you'd like
Add the following functions to the calls blacklist:
ast.literal_evalast.parsecompiledbm.dumb.open
Describe alternatives you've considered
Not sure about adding eval and exec as they are already covered by B307 and B102, respectively, and I'm not sure if duplicating them would make sense.
Additional context
References:
PR: #423
Is your feature request related to a problem? Please describe.
It is possible to crash the Python interpreter by passing sufficiently large/complex string to
ast.literal_eval,ast.parse,compile,dbm.dumb.open,evalorexecdue to stack depth limitations in Python’s AST compiler.My biggest issue is with
ast.literal_evalwhich is recommended as a safe(r) alternative toevalby both the official documentation and bandit itself, so I suspect it is commonly[citation needed] used for parsing untrusted data where some evaluation is needed, instead of usingeval, which might cause a false sense of security.Describe the solution you'd like
Add the following functions to the calls blacklist:
ast.literal_evalast.parsecompiledbm.dumb.openDescribe alternatives you've considered
Not sure about adding
evalandexecas they are already covered by B307 and B102, respectively, and I'm not sure if duplicating them would make sense.Additional context
References:
PR: #423