4 ms·

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

by orf 2y ago

itishappy 2y ago
It uses TOML for configuration.
- orf 2y ago
  Cool, thats why this is a hypothetical question
akira2501 2y ago
> yet another poorly thought out, ad-hoc homegrown config file format OpenBSD style ntpd.conf: servers 0.gentoo.pool.ntp.org servers 1.gentoo.pool.ntp.org servers 2.gentoo.pool.ntp.org servers 3.gentoo.pool.ntp.org constraints from "https://www.google.com" listen on * I mean, there's always the possibility that they used a common, well known and pretty decent config file format. In this particular case, this shouldn't be the thing that differentiates your ntpd implementation anyways.
- IshKebab 2y ago
  That config file perfectly illustrates the point. There's no need for it to be custom, and require me to waste time learning its syntax when it could just be JSON or TOML. Honestly I would even take YAML over that and YAML is the worst.
  - xorcist 2y ago
    You still have to learn the syntax even if it is expressed in json or yaml. Perhaps stating the obvious, but not every json object is a valid ntp configuration. The configuration object will always and by definition be proprietary to ntp. Expressing it as plain text allows for a trivial parser, without any of the security implications of wrapping it in a general language language ("should this string be escaped?", "what should we do with invalid utf8?"). The more simple format has survived over thirty years, is trivial to parse by anyone, and does not bring any dependencies that needs maintaining. That should count for something.
    - IshKebab 2y ago
      Sure you have to learn how to configure things but you don't have to learn basic syntax like "how do I escape a string". The fact that it has survived tells you nothing other than it's not so completely awful that someone went through the pain of fixing it. That doesn't mean it is good. There are plenty of awful things that survive because replacing them is painful due to network effects. Bash for example.
amiga386 2y ago
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.
- vlakreeh 2y ago
  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.
- kelnos 2y ago
  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.)
  - 2y ago
patmorgan23 2y ago
Why isn't there a decent parser in the standard library? More than 50% of programs will probably touch json at this point.
- tialaramex 2y ago
  Rust's stdlib is (at least notionally) forever. Things in the standard library (including core and alloc) get deprecated but must be maintained forever, which means that "at this point" isn't enough. In 2003 those programs would have used XML, in 1993 probably .INI files. Are you sure that despite all its shortcomings JSON is the end of history? I don't believe you. If you want "at this point" you can, as software does today, just use a crate. Unlike the stdlib, if next week Fonzie files are huge and by 2026 "nobody" is using JSON because Fonzie is cool, the JSON config crate merely becomes less popular.
cozzyd 2y ago
JSON is a terrible configuration format since it doesn't support comments.
- orf 2y ago
  Ok. Do you want to now add anything relevant to the comment you’re replying to?
  - cozzyd 2y ago
    As a user, I always prefer the bespoke configuration file format, provided it has comments explaining what each configuration option does.
  - petee 2y ago
    Its an entirely relevant response...they are saying what you call a poorly thought out adhoc format is still better than json in any form or dependency. Ironically your snark isnt relevant.
    - orf 2y ago
      Could be instead YAML or TOML. The point wasn’t specifically and only a JSON dependency, it was a dependency in general to do something useful and standardised
      - petee 2y ago
        > Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format Ok, but you didn't write that, and thus they responded as such. Snark was still unnecessary; they made a simple statement in reply.

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

by orf 2y ago

Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format?

itishappy 2y ago

It uses TOML for configuration.

orf 2y ago
Cool, thats why this is a hypothetical question

akira2501 2y ago

> yet another poorly thought out, ad-hoc homegrown config file format OpenBSD style ntpd.conf: servers 0.gentoo.pool.ntp.org servers 1.gentoo.pool.ntp.org servers 2.gentoo.pool.ntp.org servers 3.gentoo.pool.ntp.org constraints from "https://www.google.com" listen on * I mean, there's always the possibility that they used a common, well known and pretty decent config file format. In this particular case, this shouldn't be the thing that differentiates your ntpd implementation anyways.

IshKebab 2y ago
That config file perfectly illustrates the point. There's no need for it to be custom, and require me to waste time learning its syntax when it could just be JSON or TOML. Honestly I would even take YAML over that and YAML is the worst.
- xorcist 2y ago
  You still have to learn the syntax even if it is expressed in json or yaml. Perhaps stating the obvious, but not every json object is a valid ntp configuration. The configuration object will always and by definition be proprietary to ntp. Expressing it as plain text allows for a trivial parser, without any of the security implications of wrapping it in a general language language ("should this string be escaped?", "what should we do with invalid utf8?"). The more simple format has survived over thirty years, is trivial to parse by anyone, and does not bring any dependencies that needs maintaining. That should count for something.
  - IshKebab 2y ago
    Sure you have to learn how to configure things but you don't have to learn basic syntax like "how do I escape a string". The fact that it has survived tells you nothing other than it's not so completely awful that someone went through the pain of fixing it. That doesn't mean it is good. There are plenty of awful things that survive because replacing them is painful due to network effects. Bash for example.

amiga386 2y ago

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.

vlakreeh 2y ago
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.
kelnos 2y ago
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.)
- 2y ago

patmorgan23 2y ago

Why isn't there a decent parser in the standard library? More than 50% of programs will probably touch json at this point.

tialaramex 2y ago
Rust's stdlib is (at least notionally) forever. Things in the standard library (including core and alloc) get deprecated but must be maintained forever, which means that "at this point" isn't enough. In 2003 those programs would have used XML, in 1993 probably .INI files. Are you sure that despite all its shortcomings JSON is the end of history? I don't believe you. If you want "at this point" you can, as software does today, just use a crate. Unlike the stdlib, if next week Fonzie files are huge and by 2026 "nobody" is using JSON because Fonzie is cool, the JSON config crate merely becomes less popular.

cozzyd 2y ago

JSON is a terrible configuration format since it doesn't support comments.

orf 2y ago
Ok. Do you want to now add anything relevant to the comment you’re replying to?
- cozzyd 2y ago
  As a user, I always prefer the bespoke configuration file format, provided it has comments explaining what each configuration option does.
- petee 2y ago
  Its an entirely relevant response...they are saying what you call a poorly thought out adhoc format is still better than json in any form or dependency. Ironically your snark isnt relevant.
  - orf 2y ago
    Could be instead YAML or TOML. The point wasn’t specifically and only a JSON dependency, it was a dependency in general to do something useful and standardised
    - petee 2y ago
      > Would you rather it had a JSON dependency to parse a config file, or yet another poorly thought out, ad-hoc homegrown config file format Ok, but you didn't write that, and thus they responded as such. Snark was still unnecessary; they made a simple statement in reply.