Choosing JSON is a bit of a WTF. Presumably you're going to have to either use canonical JSON, which makes it entirely non user editable. 'J' is from the world of browsers and all the bad things that go along with it.
YAML would be slightly more tasteful but the same problem with canonicalization exists. Clearly nothing was learned from X.509.
The alternative is to encrypt only the decoded value fields, so it's immune to format changes but that leaks all sorts of metadata unless you're really careful with you
I don't have too much of an issue with JSON. Its biggest problem, unless you use some extension, is you can't have in-line comments (which also means not being able to disable a block by commenting it).
But then last I heard YAML still has the issue of no block start/end markers meaning if a file gets cut off part way through it likely won't throw any errors (unless you're validating the content in a way that requires things that are now missing). If only they'd gone C-style instead of python "indentatio
If truncation of files is a problem on a a system, it is due to poor error handling and poor design of the tools used to change those files.
However, an extra safety check can be a good idea. In YAML:
YAML uses three dashes (“---”) to separate directives from document content. This also serves to signal the start of a document if no directives are present. Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.
...it is easy enough for libraries to provide a safe mode which makes the starting marker and those trailing dots mandatory.
That said, JSON with all its ickiness is a step forward for systemd, considering all these crappy.INI style files I keep running into in this lineage of software.
>So, what happens if the encrypted user thingamabob gets corrupted? isn't this a failure chokepoint?
The cryptographic integrity check fails.
If you don't want random corruption to corrupt your data, apply error correction after the encryption and signing. A little BCH or Reed Solomon never hurt anybody.
Backups are only as good as the data that goes into 'em. Many are the cases where the backup was found, too late, to be corrupted in the same way as the original.
Yeah, this proposed change sounds like a needless hassle, and a solution in search of a problem.
Registry (Score:5, Funny)
All user information will be placed in a cryptographically signed JSON record, such as username, group membership, and password hashes.
Hopefully Poettering will provide some kind of proprietary "Editor" for this "Registry" of information, as other similarly well-designed systems do.
Re: (Score:3)
Choosing JSON is a bit of a WTF. Presumably you're going to have to either use canonical JSON, which makes it entirely non user editable. 'J' is from the world of browsers and all the bad things that go along with it.
YAML would be slightly more tasteful but the same problem with canonicalization exists. Clearly nothing was learned from X.509.
The alternative is to encrypt only the decoded value fields, so it's immune to format changes but that leaks all sorts of metadata unless you're really careful with you
Re: (Score:3)
How else are JavaScript developers going to contribute to the OS? Do you expect them too learn C??
Now we just need to get working on porting the kernel to node.js.
Re: (Score:2)
I don't have too much of an issue with JSON. Its biggest problem, unless you use some extension, is you can't have in-line comments (which also means not being able to disable a block by commenting it).
But then last I heard YAML still has the issue of no block start/end markers meaning if a file gets cut off part way through it likely won't throw any errors (unless you're validating the content in a way that requires things that are now missing). If only they'd gone C-style instead of python "indentatio
Re: (Score:2)
If it is cryptographically signed, then any change will throw an error.
Re: (Score:2)
If truncation of files is a problem on a a system, it is due to poor error handling and poor design of the tools used to change those files.
However, an extra safety check can be a good idea. In YAML:
YAML uses three dashes (“---”) to separate directives from document content. This also serves to signal the start of a document if no directives are present. Three dots ( “...”) indicate the end of a document without starting a new one, for use in communication channels.
...it is easy enough for libraries to provide a safe mode which makes the starting marker and those trailing dots mandatory.
That said, JSON with all its ickiness is a step forward for systemd, considering all these crappy .INI style files I keep running into in this lineage of software.
Re: (Score:2)
So, what happens if the encrypted user thingamabob gets corrupted? isn't this a failure chokepoint?
Re: (Score:2)
>So, what happens if the encrypted user thingamabob gets corrupted? isn't this a failure chokepoint?
The cryptographic integrity check fails.
If you don't want random corruption to corrupt your data, apply error correction after the encryption and signing. A little BCH or Reed Solomon never hurt anybody.
Re: (Score:2)
I was thinking more like a random disk error after the data is written.
Re: (Score:2)
I guess that's what backups are for.
However I'm not here to apologize for systemd. It wasn't my idea to do this.
It sounds like a hassle to me. When I want my code to me available to me, I stuff it in a github repo and pull it wherever I am to work on it.
Re: (Score:2)
Backups are only as good as the data that goes into 'em. Many are the cases where the backup was found, too late, to be corrupted in the same way as the original.
Yeah, this proposed change sounds like a needless hassle, and a solution in search of a problem.
Re: Registry (Score:2)
Re: (Score:3)
Considering the project already provides specific tools to deal with things like the journal, i'm sure they are aware of the need.
Re: (Score:2)