This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Jeremy.Hylton, Trundle, alex, benjamin.peterson, berker.peksag, brett.cannon, daniel.urban, dmalcolm, eltoder, eric.snow, georg.brandl, gregory.p.smith, isoschiz, jcon, mark.dickinson, meador.inge, methane, nadeem.vawda, ncoghlan, pconnell, pitrou, pstch, rhettinger, santoso.wijaya, serhiy.storchaka, techtonik, terry.reedy, vstinner
Date 2017-01-31.15:59:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hugo, Serhiy, and Victor: I think you're all agreeing with each other, but to make sure I'm understanding the point correctly:

1. ast.literal_eval() is currently safe from malicious code like "100000 ** 100000" or "1073741824 * 'a'" because it only traverses addition and subtraction nodes, so any such operations will just throw ValueError (As a point of interest: unary plus and minus are required to support positive and negative numeric literals, while binary addition and subtraction are required to support complex number literals. So the status quo isn't precisely the result of a conscious security decision, it's just a minimalist implementation of exactly what's necessary to support all of the builtin types, which also provides some highly desirable security properties when evaluating untrusted code)

2. an eager constant folding optimisation in the AST tier would happen *before* literal_eval filtered out the multiplication and exponentiation nodes, and hence would make literal_eval vulnerable to remote DOS attacks in cases where it is expected to be safe

However, that's not exactly how this patch works: if you pass "PyCF_ONLY_AST" as ast.parse does, it *doesn't* run the constant-folding step. Instead, the constant folding is run as an AST-to-AST transform during the AST-to-bytecode compilation step, *not* the initial source-to-AST step. (see )

This has a few nice properties:

- ast.literal_eval() remains safe
- source -> AST -> source transformation pipelines continue to preserve the original code structure
- externally generated AST structures still benefit from the AST optimisation pass
- we don't need a new flag to turn this optimisation pass off when generating the AST for a given piece of source code
Date User Action Args
2017-01-31 15:59:23ncoghlansetrecipients: + ncoghlan, brett.cannon, georg.brandl, rhettinger, terry.reedy, gregory.p.smith, mark.dickinson, pitrou, vstinner, techtonik, nadeem.vawda, benjamin.peterson, alex, Trundle, methane, dmalcolm, meador.inge, daniel.urban, Jeremy.Hylton, santoso.wijaya, eltoder, eric.snow, jcon, berker.peksag, serhiy.storchaka, pconnell, isoschiz, pstch
2017-01-31 15:59:23ncoghlansetmessageid: <>
2017-01-31 15:59:23ncoghlanlinkissue11549 messages
2017-01-31 15:59:23ncoghlancreate