[userbinator]

Also this:

Since the user record is cryptographically signed the user cannot make modifications to the file on their own (at least not without corrupting it, or knowing the private key used for signing the record).

That sounds like something that shouldn't even be in the user's own home directory.

...and JSON, of all things. Every aspect of systemd which I've worked with seems to be full of sprawling complexity and overengineering, and this is no exception. I know "it's not the UNIX philosophy" is a common dismissive complait about it, but looking at the design gives a very different feeling than the "original UNIX" designs, which felt humble and simple.

[nullc]

Json is particularly poorly suited for data which will be digitally signed because it does not reliably round-trip. E.g. you read the data in with a parser and re-serialize the same data, the output you get will often not be bitwise identical to the input.

[lokedhs]

My favourite example of this is JSON's treatment of numbers. There it literally no way to serialise a number without putting it in a string. I'm just waiting for the first security vulnerability caused by a JSON decoder not deserialising a large integer correctly.

[Skunkleton]

They are probably “normalizing” the data before checksumming.

[clktmr]

>...and JSON, of all things.

Right? Reasoning was "the web people are using it too". Why not just use key value based config files like every other system tool?

[stubish]

Likely because, despite looking similar, those key/value and .ini style config files like every other system tool are actually hundreds of subtly incompatible or poorly specified formats. Unicode handling, whitespace handling, quoting, indentation, multi-line, line continuation, comments, non-string datatypes, lists, maps... you use YAML for human maintained and YAML or JSON for machine so people can use an off the shelf parser instead of implementing your particular key/value specification. Even TOML is better than rolling your own, since at least it has a common specification.

[imtringued]

I once found a .cfg file. It had an incomprehensibly foreign configuration format that is specific to the file. A standardized config format like YAML or JSON has lots gotchas but you can learn them once and then know forever. With custom_format5345 you have the problems of poorly designed configuration formats (lots of gotchas, sometimes more than YAML) and the downsides of having to relearn the undocumented configuration format.

[gruez]

People just like to use whatever's trendy. If this was 2 decades ago, it would be XML files.

[catalogia]

Making it JSON is just begging for users to think they can edit it. I hope they put a big banner disclaimer at the top at least. (Does JSON officially have comments yet?)

[CameronNemo]

Json does not officially slow comments, and the hjson project is unmaintained.

[mekster]

JSON is so lacking, wish they went for JSON5. I know it's not wide spread but so is what they're doing.

[mixedCase]

>...and JSON, of all things. Every aspect of systemd which I've worked with seems to be full of sprawling complexity and overengineering

boolean, number, string, array, object, null

Sounds simple to me.

[lokedhs]

Please tell me what you'll end up with if you encode and then decode the number 1E12 using two different JSON implementations. Check the spec, and then tell me if it's simple.

[zeveb]

Does the JSON number type permit me to store the number 123,456,789,098,765,432,123,456,789,098,765,432,123? When I read it in with a parser, what integer value will my code see?

This is not an academic question: large integers are common, for example, as cryptographic keys.