Optional type-method/attr access safety

[danthedeckie]

Description

Basic opt-in type checking for allowed methods rather than the current 'disallow-methods' system.

In short - it's easier to be sure we're safe if we explicitly list functions/attrs/methods that are safe rather than try to catch all the possible unsafe methods/accesses.

This would be the default in 2.x, but opt-in for 1.x to maintain backwards compatibility.

See the README in the changed files for how this should work.

(For 2.x, we should see if there's a good way to make the defaults even more stripped back - and have every feature opt-in - that would be cool?)

References:

• Remove import, functions, keywords, subscripts and attribute access. Everything should be explicitly added as extras. #81
• We should switch to explicitly giving permission for methods / data access #125

TODO

• More tests
• Check it works for dictionary access etc.
• Are there any other basic types we should allow by default?
• README / docs update about this feature.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.33%. Comparing base (b2b84bf) to head (b0ec986).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #154      +/-   ##
==========================================
+ Coverage   99.30%   99.33%   +0.03%     
==========================================
  Files           2        2              
  Lines        1151     1209      +58     
==========================================
+ Hits         1143     1201      +58     
  Misses          8        8              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[danthedeckie]

Just wondering... do we also need any kind of checks for the types that can have various operators applied to them?

>>> import simpleeval
>>> class Foo:
...     def __add__(self, other):
...         raise Exception('alas!')
...
>>> simpleeval.simple_eval('foo + 21', names={"foo": Foo()})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 768, in simple_eval
    return s.eval(expr)
           ^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 433, in eval
    return self._eval(previously_parsed or self.parse(expr))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 445, in _eval
    return handler(node)
           ^^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 448, in _eval_expr
    return self._eval(node.value)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 445, in _eval
    return handler(node)
           ^^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 502, in _eval_binop
    return operator(self._eval(node.left), self._eval(node.right))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/daniel/src/simpleeval/simpleeval.py", line 272, in safe_add
    return a + b
           ~~^~~
  File "<stdin>", line 3, in __add__
Exception: alas!

I don't think there's any security concerns - but just wondering if the various safe_add etc things would / could also need type checking for allowed types or something...

[kurtmckee]

That may be worthwhile, but I don't recommend expanding the scope of this PR.