That's how most analysis tools work. Not necessarily 'dynamic' languages even, e.g.
- Clang (depending on warnings level) may reject a valid program -- doesn't make it less useful, you just suppress the check for the offending line and carry on
- Rust borrow checker may be seemingly picky and reject a perfectly valid program form your viewpoint. Does it make it less useful? I wouldn't say so.
Right, but if you've introduced the ability to ignore the validator then you've traded away the guarantee that your config program will be safe to execute.
My point is that the validator can't give you the safety property that is claimed as a defence against one of the inherent issues with this approach.
Ah, maybe I wasn't clear enough there -- the validator/analyser is supposed to run by both parties, the party who writes config, and the party who loads it as well. So you can reject a malicious config before trying to execute it.
I mostly have a non-malicious user in mind though (i.e. end-user software, where the software and the config have same permissions)
If you do have such security concerns, you probably need a sandbox at some point. E.g. big source of my frustration are CI pipelines -- they run isolated anyway and execute arbitrary code. Having a YAML there does nothing for the security.
Even if I'm not concerned with a malicious actor, I ought to be concerned about silly future me that accidentally introduces an infinite loop into the config, which then makes it to production and is able to wreak havoc, because silly past me had to disable the validator for this config because of "that pesky validator bug that only shows up on Tuesdays"...
- Clang (depending on warnings level) may reject a valid program -- doesn't make it less useful, you just suppress the check for the offending line and carry on
- Rust borrow checker may be seemingly picky and reject a perfectly valid program form your viewpoint. Does it make it less useful? I wouldn't say so.