3 ms·

python eval() is the root of all evil. Basically if the library uses eval() it's probably a good idea to avoid it if possible.

• baeaz 4y ago
  That makes me think - would it be possible to have a runtime or build time option for cpython that removes eval() ?
  • bb88 4y ago
    Probably. But python missed their chance to nix it with the 2->3 transition. My favorite case was when a newbie coder used eval() to evaluate something that looked json-ish, which, came from an api request.
    • dtgriscom 4y ago
      Simple and powerful. Gotta love it (until your customer doesn't, big-time).
  • theptip 4y ago
    If you run a security linter like ‘bandit’ you’ll get warnings for eval and other security holes. It seems you can’t run bandit on deps, but perhaps if you fork them and build yourself? If you are security conscious, having a rule that you can only install from a local pypi with packages you have forked would be a more defensible perimeter. But, a maintenance pain for sure.
• dylan604 4y ago
  but python is not the only language to have an eval(), so why is python's in particular the root of all evil?
  • tiagod 4y ago
    It's not literal.
• zzzeek 4y ago
  that doesn't make much sense and there are necessary uses for eval() /exec(), mostly for dynamic creation of code: For example here's Python dataclasses in the standard library using exec() to create the `__init__` and other methods that go on your dataclass: https://github.com/python/cpython/blob/main/Lib/dataclasses.py#L451 https://github.com/python/cpython/blob/main/Lib/dataclasses.... Here's Pydantic using it for a jupyter notebook check: https://github.com/pydantic/pydantic/blob/594effa279668bd955e98f1cd5c036b37d3bbd40/pydantic/_internal/_validation_functions.py#L150 https://github.com/pydantic/pydantic/blob/594effa279668bd955... here's Pytest using it to rewrite modules so that functions like assert etc. are instrumented by pytest: https://github.com/pytest-dev/pytest/blob/eca93db05b6c5ec1012f7a3e6590f316729ac243/src/_pytest/assertion/rewrite.py#L168 https://github.com/pytest-dev/pytest/blob/eca93db05b6c5ec101... Here's the decorator module using it (as is the only way to do this in Python) to create a signature matching decorator for an arbitrary function: https://github.com/micheles/decorator/blob/ad013a2c1ad7969963acf3dea948632be387f5a0/src/decorator.py#L160 https://github.com/micheles/decorator/blob/ad013a2c1ad796996... All of these libraries are completely secure as eval/exec are used with code fragments that are generated by the libraries, not based on untrusted input. eval() /exec() are not running executable files, just Python code, the same way all the rest of the package is already doing.
  • bb88 4y ago
    Right, and each one of those is a potential exploit waiting to happen.
    • zzzeek 4y ago
      please support your assertion. I would also recommend opening CVEs detailing your discovered attack vectors, especially that of Python dataclasses in the standard library, which are in very widespread use. If you do in fact have some insight on how Python dataclasses are an "exploit waiting to happen", I think it's irresponsible to just sit on that information.