LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Closed Thread
 
Search this Thread
Old 06-13-2013, 03:08 AM   #481
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234

Quote:
Originally Posted by ReaperX7 View Post
I'd rather create something, if I could, that was optional in every way and only enhanced what was already there.
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.
 
Old 06-14-2013, 05:32 PM   #482
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware [64]X{.0|.1|.2|-current} ::X>=12<=14, FreeBSD_10{.0|.1}
Posts: 2,171

Rep: Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849Reputation: 849
Undocumented log format?

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:

Quote:
"The systemd journal is in a binary format which is (according to what I read about this last time) purposely undocumented to stop people from implementing interoperable software without having to reverse-engineer (and re-reverseengineer and so on) the parts of systemd dealing with these files in order to be able read them, IOW, its is purposely designed to make interoperability difficult..."
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...

Last edited by astrogeek; 06-14-2013 at 05:32 PM. Reason: Typo
 
Old 06-15-2013, 05:51 PM   #483
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Originally Posted by astrogeek View Post
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.
http://www.freedesktop.org/wiki/Soft...journal-files/
 
Old 06-17-2013, 07:28 PM   #484
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.
 
Old 06-17-2013, 07:55 PM   #485
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by ReaperX7 View Post
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 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.
Quote:
Originally Posted by ReaperX7 View Post
I think it's also illegal under certain licenses also, including many popular open source licenses.
Now you're just making stuff up.
 
Old 06-17-2013, 08:09 PM   #486
elvis4526
Member
 
Registered: Aug 2011
Posts: 114

Rep: Reputation: Disabled
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 ?
 
Old 06-17-2013, 08:20 PM   #487
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,808

Rep: Reputation: 234Reputation: 234Reputation: 234
What is the benefit of keeping log files in a binary format?
 
4 members found this post helpful.
Old 06-17-2013, 09:22 PM   #488
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
Quote:
Originally Posted by rkelsen View Post
What is the benefit of keeping log files in a binary format?
No benefit at all really.

Quote:
Originally Posted by T3slider View Post
Now you're just making stuff up.
What part of "I think..." was just not understood there?

Laws on encryption and encryption algorithms vary country by country.

Quote:
"The systemd journal is in a binary format which is (according to what I read about this last time) purposely undocumented to stop people from implementing interoperable software without having to reverse-engineer (and re-reverseengineer and so on) the parts of systemd dealing with these files in order to be able read them, IOW, its is purposely designed to make interoperability difficult..."
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.

Last edited by ReaperX7; 06-17-2013 at 09:31 PM.
 
Old 06-17-2013, 10:49 PM   #489
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
Old 06-18-2013, 12:07 AM   #490
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.
 
Old 06-18-2013, 09:56 AM   #491
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,239

Rep: Reputation: 178Reputation: 178
Quote:
Originally Posted by ReaperX7 View Post
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/

Last edited by jens; 06-18-2013 at 10:16 AM.
 
Old 06-18-2013, 10:47 AM   #492
jens
Senior Member
 
Registered: May 2004
Location: Belgium
Distribution: Debian, Slackware, Fedora
Posts: 1,239

Rep: Reputation: 178Reputation: 178
Quote:
Originally Posted by the3dfxdude View Post
If I understand what Reaper was saying here, the dependencies he was asking about go opposite way. Your quotes don't address that.
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).

Last edited by jens; 06-18-2013 at 11:49 AM.
 
Old 06-18-2013, 03:49 PM   #493
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
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.
Old 06-18-2013, 05:02 PM   #494
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
Quote:
Originally Posted by jpollard View Post
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.
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.
 
Old 06-18-2013, 06:11 PM   #495
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by ReaperX7 View Post
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.
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.
  


Closed Thread

Tags
cgroups


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 05:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 12:07 PM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 05:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 12:40 PM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 10:02 AM


All times are GMT -5. The time now is 09:25 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration