A little over a year ago I posted a story called “Configuration files are a canary, warning us of potential security issues”. My basic argument was that it was fundamentally bad for security to have people growing software stacks by adding new configuration formats willy-nilly. No single person ends up having a global view of what languages the stack has, where the security risks lie, and which tools are open to those security risks. In response, I described a thought experiment of a single stack with just two languages: a statically typed compiled low-level language, and a dynamically typed interpreted high-level language. A fundamental design goal would be to avoid creating new languages in the system. Creating any sort of config file parser would be forbidden in this system. Just use the available HLL. For example, if your HLL was Javascript, make on this system would use JSON or something like that. That way you only have to nail down string quoting and escaping in one place.
(Since this is a thought experiment, let’s not get hung up on which languages we choose to include. Just assume it’s your favorite languages. Obviously, ed would be right out.)
I’ve been unable to stop thinking about this idea, and after recently chatting with @rain1 I came up with an ironclad refutation:
Anytime you added a feature to the single HLL on the stack, you would need to think through all the programs that use it as a configuration language, to look for misuse of the new feature.
This probably seems very abstract, refuting a private thought experiment, but I thought I’d throw it out here in case anyone else ends up thinking about similar ideas.
Thought experiments seem like an under-utilized practice. The nice thing about a thought experiment is that it lets us “be careful what we wish for” without impacting the world by getting people to change their habits and start using something potentially sub-optimal. It’s a way to try to “first do no harm”. And they’re cheap. Now that this thought experiment is dead in the water, I can go off and think of other, hopefully better ideas.
What about if your HLL is declarative and non-turing complete? Something like Dhall. Seems like the dhall interpreter could find a bunch of misuse problems.
That would help, but the key is perhaps not letting the HLL change. Is Dhall pretty stable?
This would seem to indicate that it isn’t and I don’t see any official releases on the github page.
Does that kill the idea? Perhaps I’ve misunderstood, but is it saveable with the notion that the system can know:
Think about something like ‘go fix’ which programmatically move you from one version to another.
Either at language upgrade time, or at config file load time, you could run language upgrade steps and checks.
The problem isn’t changing all programs, it’s thinking about the security ramifications of all tools, and the programs they could receive, that may not actually be in the system at the moment.
I do appreciate the attempt :)
How would you prevent any user of this stack from implementing a programming language and using it to configure a component of itself? Lots of genuine problems to be solved with a computer program involve implementing a language of some kind - the command line flags to
ls, even, form something like a small DSL.Oh, I should clarify that I was never trying to restrict what end users do with the stack. The goal was only to shift the out-of-the-box experience to more parsimonious defaults, and to shift the expectations of end users – if a system is profligate in the number of languages it uses, that should be cause for question. All things being equal, prefer stacks with fewer languages.
I agree, commandline flag creep is also a problem. It’s been addressed before by people like Russ Cox. The DSL nature is even more apparent with
find.I was kinda always aware that the notion of “language” is not very well-posed, but this doesn’t seem like a big issue. With a little taste we can recognize a language when we see it, and ask if we can use an off-the-shelf alternative rather than brewing new moonshine. Our world is filled with reasoning around terms we can’t precisely define.
I think just considering the number of languages in a system would level up the conversation around what constitutes good design.