ISibboI
commented
2 years ago While I had no untrusted expressions in mind while programming evalexpr, I believe that the possibilities of abuse are low. You should limit the expression length though as you said, and keep in mind that the user can use the builtin functions. These are nothing dangerous, but might be helpful when doing denial of service.
Also keep in mind that when using functions like eval_number (that do not take a context as argument), a mutable context is implicitly provided. That context lives only until the function returns, so it is not like there would be any side-effects. However, using e.g. the regex_support feature flag, it is possible to build an exponentially large string with regex replacements. So you should disable that feature.
As far as I could make sure, the code does not panic, but returns a Result::Err on error, so it should be quite hard to do denial of service by shooting down your processes. Any panic is treated as bug.
My use case is an application that users submit expressions to over the Internet, which are then evaluated to floats. It it can't, it should just fail. I would like to know if this crate is suited to that.
I am currently using fasteval, but its last update was 2 years ago, and it has some questionable elements. But fasteval was appealing to me because its readme actually makes the claim that it is designed for safe evaluation of untrusted expressions.
Looking at evalexpr's documentation,
eval_numbersounds exactly like what I want. But I would feel better if you said somewhere that you had untrusted input in mind when developing.I don't expect evalexpr to provide safety against excessively processing-intensive calculations, because I consider that my own application's responsibility. And due to the nature of Rust, I find it unlikely there would be some memory leak from contextless evaluation. But honestly I just don't know all the things that can go wrong.