I'm still not sure about why you want to do this. It is quite a task... and probably for little-to-no gain.

Anyhow, good luck with it.

I recall reading several months ago that the systemd log data would be encrypted in a way that would not be documented, "for security" as I recall. I have refrained from mentioning that in this thread because I did not have the original article, but my recollection is that Lennart hisself said that.

Apparently I am not the only one to have seen it as I found the following comment to an article on Linux Today:

Is this as true as it appears to be? Does that trouble anyone?

Please, no flames about the source, the commenter, the context, etc., etc...

So if the log data is encrypted, then the logs are useless unless you have the decryption algorithms. Failing to provide any decryption method, even if only for a critical software feedback and usage tracking system, is not in the spirit of open source software. I think it's also illegal under certain licenses also, including many popular open source licenses.

I believe the forward secure sealing stuff is optional. I haven't seen it in practise, but the logs are originally sealed with a sealing key, and subsequent log blocks are sealed with a key derived from that sealing key. They are verified by a separate verification key that the user stores somewhere else (like a piece of paper). I have no idea if the logs themselves are obfuscated or if it is just a verification method to detect log modification, but the logs are readable without the verification key. Someone with experience would have to speak to that. As for the algorithms, the source is open, and the algorithms have been explained.
Now you're just making stuff up.

You have no obligation to encrypt the journal but if you want to, of course you can decrypt it after.

What would be the use of an undecryptable log file anyway ?

What is the benefit of keeping log files in a binary format?

4 members found this post helpful.

No benefit at all really.

What part of "I think..." was just not understood there?

Laws on encryption and encryption algorithms vary country by country.

I do know for certain that in several countries purposely not providing proper documentation into something as such like encryption methods, or even using encryption outright, is illegal, and punishable under penalty of law. This will vary country by country, and the same may not apply to you, but it will to someone else.

By purposely undocumenting the binary format in several countries this would be seen as a type of encryption, and systemd would be illegal software to use, distribute, or even possess. I doubt I need to remind people that there are countries like this in existence, one of which has been talked about already in these forums.

If you want to make this argument, then Slackware is already illegal. It ships gpg, openssl, etc. Regardless, you initially implied not that undocumented binary formats were illegal, but that they violated open source licenses. This makes no sense at all, especially since systemd is entirely open source.
Did you read wildwizard's link? It is documented (thus this discussion is moot). Plus, it is open source anyway -- decrypting the binaries would require studying code, not reverse engineering anything.

Please stop selectively reading...

2 members found this post helpful.

Slackware already is illegal in China, but a distribution of Linux based on Slackware, or something similar, does exist in China but with all encryption software removed that is legal to use and distribute.

There's an official debian mirror provided by the University of Science and Technology of China (read government):
http://www.debian.org/News/2011/20110525

Notice how it's hosting everything Slackware as well (even -current, no changes):
http://ftp.cn.debian.org/slackware/

It does ... Those dependencies are all inside that one distro package ...
Only a very small minority of them go downwards (everything else is meant to replace/support/glue existing with added systemd-only stuff in a modular/optional way).

It is why udev has been forked.

My problem with systemd is that you cannot trust it to get things right. It takes a LOT of effort to add a new service because you have to know EVERYTHING about that new service, and nearly everything about the existing services to get the dependency lists right.

It frequently goes into multi-user mode without a functioning network... so any services needing a network will fail.

You can't use the "emulated sysVinit" because it doesn't get it right either - is neither properly emulated (all services are started in parallel) or it fails due to the network.

The rc.local script that is supposed to run after everything else still can run before the network is ready...

And then there is the interdependencies between udev, systemd, dbus, NetworkManager... in that a failure in one of them may cause a crash (especially with the first 3).

I haven't used F19 yet (they just fixed yet another hang).

I'm strongly prefer the Slackware way - more reliable. Error logs can show exactly what failed, where, and when. Not so with systemd - error message can be mixed (granted, only on a message by message basis) that they had to create yet another log system to try and cure that. I still think error messages can and will be lost due to the complexity involved.

1 members found this post helpful.

This is why I fail to understand why there is such a uninformed rush, like ArchLinux did, to implement systemd without it being matured well enough to be reliable in the long run.

The Parallel service starting system works on paper, but even Gentoo and OpenRC have said that starting services in Parallel is experimental in nature because if a dependency service is started after it is required the service that depends on it can not function, and why Linear mode is recommended.

This is why I said numerous times, yet it fell on deaf ears, that systemd is Alpha class software, nowhere near ready even by Red Hat's estimates, to be mass deployed or even used as a core system daemon.

Five years from now, it might be ready, it might be matured enough, it might even be stable enough, and work properly to be a full successor to SysVInit, but it's not there yet, and 5 years time might still be a rough estimate. It might not ever be ready.

This must be the reason why RHEL 7, scheduled for the second half of 2013, will come with systemd as init system. Where did you get the information that Red Hat thinks systemd is not production ready?

1 members found this post helpful.