Comment by amiga386 | Hacker News Reader

Comment by amiga386 | Hacker News Reader

Parent Full thread

Poorly thought out, ad-hoc homegrown config file format, please. Every time.

1. Code doesn't change at the whims of others.

2. The entire parser for an INI-style config can be in about 20 lines of C

3. Attacker doesn't also get to exploit code you've never read in the third party dependency (and its dependencies! The JSON dependency now wants to pull in the ICU library... I guess you're linking to that, too)

4. Complexity of config file formats are usually format-independent, the feature-set of the format itself only adds complexity, rather than takes it away. To put it another way, is this any saner...

    {"user":"ams","host":"ALL","runas":["/bin/ls","/bin/df -h /","/bin/date \"\"","/usr/bin/","sudoedit /etc/hosts","OTHER_COMMANDS"}

... than ...

    # I may be crazy mad but at least I can have comments!
    ams ALL=/bin/ls, /bin/df -h /, /bin/date "", /usr/bin/, sudoedit /etc/hosts, OTHER_COMMANDS

All the magic in the example is in what those values are and what they imply, the format doesn't improve if you naively transpose it to JSON.

An example of an NTP server's config:

    # I can have comments too
    [Time]
    NTP=ntp.ubuntu.com
    RootDistanceMaxSec=5
    PollIntervalMinSec=32
    PollIntervalMaxSec=2048

If you just want key-value pairs of strings/ints, nothing more complex is needed. Using JSON is overdoing it.

1. I can pin my json parser dependency and literally never update it again

2. And how many times have we seen 20 lines of C backfire with some sort of memory safety issue.

3. First off, i'd go out on a limb and say the number of attacks from a well-established (or even a naive one) rust json parsing library is dwarfed by the number of attacks from adhoc config parsers written in C with some overlooked memory safety issue.

4. Usually being the key word, tons of adhoc config formats have weird shit in them. With json (or yaml/toml) you know what you're getting into and you immediately know what you're able and unable to do.

I feel like using the incomprehensibly error-prone and inscrutable sudoers format as an example kinda argues against your point.

(I do agree that JSON is a terrible configuration file format, though.)

My argument was not that sudoers is good - it's crazy overcomplicated.

My argument was data interchange format standards are orthogonal to config files. They don't have the same goals.

A programmer who thinks "I'll use JSON|YAML|TOML for my config file" - well, you didn't solve your first problem (what should the config look like, in a way that makes sense and is easily readable, understandable, updateable by the user) and you added a second problem before you even started solving the first - whatever your config looks like, it now also has to be 100% compliant with some data interchange format and support all its features, and that's going to require a lot of code - and then we get into whether you write the compliant parser/generator, or if someone else does and you do/don't audit every line of it. And then on top of that you add an additional pile of code to parse/generate whatever your actual config format is.

I once saw an .ini for a log parser:

    [Alarm]
    Name=Nginx Errors
    Pattern="[error] <pid>#<tid>: <message>"

The thing worked. Without any errors. And yet it took:

    Pattern="[error] <pid>

..and then considered the rest of the line a comment. It didn't even error on the fact that the quotes were not closed.

Hand-rolling config formats is hard.

Yeah try adding a git alias with quotes... I ended up reading the source code to figure out wtf it was doing.

Reply on news.ycombinator.com