Well, with all the enshitified complex file formats out there, I bet this is a "piece of cake" (for the people of the field with good tooling) to find exploits in the state management of code dealing with them. And very high computer languages/specialized script languages won't protect anything as those are "logic errors". I think "closing" state machines on such complex file formats is just pointless, better design new file formats from the ground up, but this time with a much stronger focus on robustness (keep that state machine as small and simple as possible and super rigorously well defined, and I mean like maths maniacs). And it is hard: because the purpose of the file format must come AFTER the robustness, namely tough compromise on the purpose itself may have to be done.
Also taking DJB advice - "do not parse" - looks to be more relevant then ever before :) That directory of (mainly) one-line configuration files is really nice to have...
And "config files written in X lang" should seriously and officially be considered as bad-bad thing, worse then XML :)
And languages that have eval or functions re-definitions available at runtime should be considered only in jokes in production environment. And products that use them should be send in outer space direction, just like Voyager ;)
Actually, Turing complete languages are way too much in use. We do not need so much of their powers, especially after deployment.
sylware · · focus · HN ↗
Woodi · · focus · HN ↗
And "config files written in X lang" should seriously and officially be considered as bad-bad thing, worse then XML :)
And languages that have eval or functions re-definitions available at runtime should be considered only in jokes in production environment. And products that use them should be send in outer space direction, just like Voyager ;)
Actually, Turing complete languages are way too much in use. We do not need so much of their powers, especially after deployment.