NEnetworked·Nov 20, 2024
All right, let me tell you the history of recur to explain this choice. :-)
I wrote the initial version in Python in 2023 and used simpleeval [1] for the condition expressions.
The readme for simpleeval states:
> I've done the best I can with this library - but there's no warranty, no guarantee, nada. A lot of very clever people think the whole idea of trying to sandbox CPython is impossible. Read the code yourself, and use it at your own risk.
In early 2024, simpleeval had a vulnerability report that drove the point home [2].
I wanted to switch to a safer expression library in the rare event someone passed untrusted arguments to `--condition` and as a matter of craft.
(I like simpleeval, but I think it should be used for expressions in trusted or semi-trusted environments.)
First, I evaluated cel-python [3].
I didn't adopt it over the bi
Read the rest
nary dependency on PyYAML and concerns about maturity.
I also wished to avoid drastically changing the condition language.
Next in line was python-starlark-go [4], which I had only used in a project that ultimately didn't need complex config.
I had been interested in Starlark for a while.
It was an attractive alternative to conventional software configuration.
I saw an opportunity to really try it.
A switch to python-starlark-go would have made platform-independent zipapps I built with shiv [5] no longer an option.
This was when I realized I might as well port recur to Go, use starlark-go natively, and get static binaries out of it.
I could have gone with cel-go, but like I said, I was interested in Starlark and wanted to keep expressions similar to how they were with simpleeval.
[1] https://github.com/danthedeckie/simpleeval
[2] https://github.com/danthedeckie/simpleeval/issues/138
[3] https://github.com/cloud-custodian/cel-python
[4] https://github.com/caketop/python-starlark-go
[5] https://github.com/linkedin/shiv#gotchas