Safe (??) eval()

[bvdp]

In another thread sciurius suggested a change to the safe_eval() code. I have no objections. I think trying to make everything in a bit of code is pretty much "going down the rabbit hole" stuff. And, frankly, a lot of the discussions are beyond my little brain. And, even more, I sort of expect people using MMA to be honest

That said, sciurius suggests that using empty __builtins__ makes eval() safe. It is echoed in this post:

    http://lybniz2.sourceforge.net/safeeval.html

I'm pretty sure that it is "safe enough". But, of course, if you read posts like:

   https://stackoverflow.com/questions/35804961/python-eval-is-it-still-dangerous-if-i-disable-builtins-and-attribute-access

there are the pundits who err on the safe (no pun intended) side and suggest that no eval() can ever be made safe.

Remembering that I did write my mma code for this many years ago, perhaps it's time for a re-eval (opps, more puns). I think I'll go with the suggestion. Comments before commit?

Oh, it was also suggested to add a call to fetch env variables. Yes, that's a good idea. I think I would use that for getting the values mma is using already. Not sure what other values would be useful, but it seems pretty easy to do.

Comments?

[sciurius]

In any case, you should only run code that you either self understand, or comes from a trusted source. Asn MMA song (or groove) is safe until it uses eval expressions $(...) or plugins. So always look at the code! Even without python skills you can see that

   1 + $PUSH0

between $( ) looks quite safe, and when you see something weird like

   [c for c in ().__class__.__base__.__subclasses__() if c.__name__ == 'catch_warnings'][0]()._module.__builtins__

(in short, anything you do not immediately understand) it is a no go. Period.

So do we trust MMA users to know what they are doing? I think so. Times have changed and everyone nowadays using computers (and mobiles, ...) should be aware that there may be risks involved and how to stay safe.

Bottom line: Pseudo-safety measures like crippling $(...) and annoying plugin warnings may go.

OTOH I cannot foresee real need for python powers in $(...). Currently all library files just use simple addition math (except for some arguably contrived examples). Do you really think someone will find a use for 'e' or 'pi' in an MMA song? Using 'pi' in $(...) gives an error anyway. 'hypot' and hyperbolic functions? Really? I think basic math (add, subtract, multiply, divide) will be sufficient. It is easy to write a python function that evaluates just that, without using eval.

[sciurius]

Attached a patch to implement macro functions, e.g. $_Env(...) and $_NoteLen(...). It can easily be augmented to implement more functions, should that be desired.

[bvdp]

Are you suggesting we do away with the current safe_func() code and the list of "permitted" calls and restricting things only to simple math and ENV()? I've just looked at my own songs and find that all my calls to $() are simple math like "Tempo $( 100 * 2 ". In the contrived egs/misc there are some calls to INT and some string functions.

 I'd included some of the other math stuff for the creation of interesting volume curves, etc.

Oh, and the suggested fixes to safe_eval() don't work with python3. I've spent some time looking at the code, but have no idea why not.

[sciurius]

safe_eval and all the math stuff have been implemented long(?) before there were plugins. I'd say plugins are much more appropriate and suitable to construct fancy volume curves, etc..
As you found out all current use of $(...) is basic math, so it will be much easier and future proof to provide just that. And real safe.

I'm willing to provide the code if you want.

[bvdp]

Yes, I think you are right ... things are getting too complicated in basic MMA. Let me think on it for a day or so ... I'll have a hack on the eval() stuff and see how I can make life work