This was not designed for end users, it was designed for programmers who want to implement their very specific network configuration requirements - in a language well suited for the task where dynamic configurations are easy to implement properly. One could implement an end-user solution using my language - the language is certainly powerful enough. But I don't have any plans to do that myself, writing scripts is good enough for me.

Attack surface? Not really. The parts of NCD which are exposed are basically:

- Integrated DHCP client (runs in the same process, as root). This is really just DOS attacks with a flood of DHCP packets, but the design ensures this may at most result in high CPU usage as well as DHCP not working, not in NCD stopping doing other things. But if the attacker can DHCP flood you he can also do worse damage with ARP poisoning. I don't believe I have arbitrary code execution bugs in NCD, especially not in the DHCP code. I'm a very careful programmer ;)

- IPC interface (request_server). The most questionable part here is probably the Lemon parser parsing NCDValues. Things like: ["key1":"val1", "key2":{"elem1", "elem2", "elem3"}].

Then there's also the security bugs the programmer writing NCD code does. Like, if he accepts an IP address obtained from a DHCP server without doing any sort of checks (in particular if overlaps with localhost / private network / VPN).

But basically, I don't think "possible security bugs" is a valid argument against any new technology. NCD is not inherently more vulnerable than any other system for network configuration.