undefined | Better HN

0 pointsjfindley11y ago0 comments

I'd be very interested to see a qualified crypto expert on the "sealing" that journald uses. This is one of two indicators of a troubling level of arrogance from the developers. The crypto method used by journald to verify messages haven't been tampered with is called Forward Secure Sealing [0]. It's based on an invention of the brother of Lennart - the lead developer, and for a long time after first release even the whitepaper describing it in detail was "coming soon" The code he finally produced is [1] - but rather light on documentation. I'm still unaware of any proper analysis of this, and using your brothers own crypto methods and ignoring all the questions this has raised does not come across well - and appears to seriously violate the "don't roll your own crypto system" rule.

The second indicator is the attitude to bugs, of which [2] is a good example - several of the developers appear to be extremely defensive towards any suggestion of defects in their software, and simply close bugs blaming the users, other software, anything else.

I'd be hopeful that RedHat manage to reign this behavior in, but that didn't seem to work for Ulrich Drepper when he was employed by RedHat to work on glibc, and I'm not sure if it's going to work here.

That said - I'm not in the "systemd is awful" camp - I do think there's a whole bunch of things it does really well, and that a lot of the hate is really quite reactionary - but the thing that frustrates me is that between the haters and the supporters, there are important questions that are getting lost in the noise.

[0]: http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

0 comments

tene11y ago

I just can't agree with your [2] as a problem. The actual problem (an assertion failure in systemd) was fixed, several alternative workarounds are provided in case the user can't or doesn't want to upgrade systemd immediately, and functionality changes about when and where and how to log were going on on the mailing list, as they should be, and the reporters were directed there politely, even after violent vitriolic attacks. After discussion concluded on the mailing list, systemd was changed to direct debug logs away from kmsg as soon as journald is available.

I can't find anything to complain about from the systemd team on that bug report. I'd just dismiss it as varying personal standards of politeness, but the complaints on that bug report are themselves far far worse, with vitriolic abuse and death threats, so there's got to be something else going on here.

vezzy-fnord11y ago

There's also this: https://bugs.freedesktop.org/show_bug.cgi?id=73729

Their attitudes towards journal log corruption have been rather apathetic, as well, though I cannot find the particular bug report at the moment.

dale-cooper11y ago

That discussion escalated quickly.. What i got from the thread is that systemd will only work with glibc, intentionally? If that's the case then it's kind of sad. Since systemd will become the standard glibc will be the only alternative.

xorcist11y ago

Relevant work in the area is Log Hash Chaining as described in RFC 5848, which at least has been through some peer review.

I don't know why they chose to ignore that, let alone what their design is really supposed to guard against. Their design allows an attacker a window of 15 minutes where they can rewrite the log at will.

So the short of it is: Keep using remote logging. Authenticate that. Don't rely on journald.

(I too have had Drepper vibes about the whole situation for quite some time. But a new init standard was long overdue and if distros can finally rally around systemd it might be worth it.)

dale-cooper11y ago

I like linus comment[0] about a workaround on the issue in your 3rd link.

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

JetSpiegel11y ago

From your [2]: Like for the kernel, there are options to fin-grain control systemd's logging behaviour; just do not use the generic term "debug" which is a convenience shortcut for the kernel AND the Base OS.

[2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Hello7111y ago

all I got from [2] is "if you would like to have productive discussion, move to the mailing list. if not, prepare to be banned."

j / k navigate · click thread line to collapse

0 pointsjfindley11y ago0 comments

[0]: http://lwn.net/Articles/512895/ [1]: https://github.com/mezcalero/fsprg [2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

0 comments

tene11y ago

vezzy-fnord11y ago

There's also this: https://bugs.freedesktop.org/show_bug.cgi?id=73729

Their attitudes towards journal log corruption have been rather apathetic, as well, though I cannot find the particular bug report at the moment.

dale-cooper11y ago

xorcist11y ago

Relevant work in the area is Log Hash Chaining as described in RFC 5848, which at least has been through some peer review.

So the short of it is: Keep using remote logging. Authenticate that. Don't rely on journald.

(I too have had Drepper vibes about the whole situation for quite some time. But a new init standard was long overdue and if distros can finally rally around systemd it might be worth it.)

dale-cooper11y ago

I like linus comment[0] about a workaround on the issue in your 3rd link.

[0]: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

JetSpiegel11y ago

[2]: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Hello7111y ago

all I got from [2] is "if you would like to have productive discussion, move to the mailing list. if not, prepare to be banned."

j / k navigate · click thread line to collapse