1 |
On Thu, Feb 20, 2014 at 5:37 PM, Michael Higgins <linux@×××××××.org> wrote: |
2 |
> On Thu, 20 Feb 2014 15:38:46 -0600 |
3 |
> Canek Peláez Valdés <caneko@×××××.com> wrote: |
4 |
> |
5 |
>> On Thu, Feb 20, 2014 at 3:22 PM, Tanstaafl |
6 |
>> <tanstaafl@×××××××××××.org> wrote: |
7 |
>> > On 2014-02-20 4:04 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
8 |
>> >>> |
9 |
>> >>> No, actually, I think whatever is defined as the current default |
10 |
>> >>> should dictate which group should be required to do the work. |
11 |
>> > |
12 |
>> > |
13 |
>> >> I think this is where we think differently (regarding this |
14 |
>> >> particular point). The work must be done by *whomever* wants to do |
15 |
>> >> the job. So if the systemd people want to do a profile that's fine |
16 |
>> >> (and this already happened); but if they don't want to, nobody can |
17 |
>> >> force them to do it (this is academic right now, since they |
18 |
>> >> already did the [pretty trivial] work). |
19 |
>> >> |
20 |
>> >> If the systemd people did not wanted to do the job, then, since you |
21 |
>> >> can't force them, the people *not* wanting systemd would be the |
22 |
>> >> ones required to do it. And that makes absolutely no sense. |
23 |
>> > |
24 |
>> > |
25 |
>> > I think we agree, but you keep saying we don't... ;) |
26 |
>> > |
27 |
>> > The difference is, since OpenRC is the default, all of the existing |
28 |
>> > profiles are, by definition, OpenRC based profiles. So, people who |
29 |
>> > don't want systemd simply have to do... nothing! |
30 |
>> |
31 |
>> OK, I see your point. |
32 |
>> |
33 |
>> > As I said before, it is people who want systemd who currently have |
34 |
>> > to 'do something', and that is as it should be, unless/until the |
35 |
>> > default of OpenRC is changed to systemd. |
36 |
>> |
37 |
>> Agreed. |
38 |
>> |
39 |
>> Regards. |
40 |
> |
41 |
> Been following along, jumping in late. |
42 |
> |
43 |
> That does settle the issue with regard to Gentoo 'defaults' for now. As |
44 |
> I see it, if you are a desktop [l]user, then go ahead and use a quick |
45 |
> systemd default. It's good enough. And Gnome folks, from what I |
46 |
> understood, didn't have an easy opt-out choice, really. At least not |
47 |
> easy enough for me to grok right away. |
48 |
> |
49 |
> Anyway, some arguments on the other branches of this thread got me |
50 |
> thinking. Take the binary log files. This seems to be something we all |
51 |
> understand to some extent (as compared to init systems, say), whether |
52 |
> a tinkerer or enterprise user. There's now something corporate sitting |
53 |
> between me and the evil crap coming out of my daemons. |
54 |
> |
55 |
> Who logs the loggers? |
56 |
> |
57 |
> My thought was, well, say if someone else, some other, unrelated team |
58 |
> entirely, was maintaining a codebase for handling that logging data, |
59 |
> that's a way out of the monoculture of systemd that would give some |
60 |
> peace of mind. If they, as also smart, talented coders began to |
61 |
> disagree, they might have capacity to keep the project in bounds. |
62 |
> |
63 |
> So, for the hell of it, I just went to have a look at what the deal |
64 |
> might be with that binary data that hangs around and dumps to disk, |
65 |
> maybe, in one format or another. |
66 |
> |
67 |
> "This document explains the basic structure of the file format on disk. |
68 |
> We are making this available primarily to allow review and provide |
69 |
> documentation. Note that the actual implementation in the systemd |
70 |
> codebase is the only ultimately authoritative description of the |
71 |
> format, so if this document and the code disagree, the code is right. |
72 |
> That said we'll of course try hard to keep this document up-to-date and |
73 |
> accurate. |
74 |
> |
75 |
> Instead of implementing your own reader or writer for journal files we |
76 |
> ask you to use the Journal's native C API to access these files. It |
77 |
> provides you with full access to the files, and will not withhold any |
78 |
> data. If you find a limitation, please ping us and we might add some |
79 |
> additional interfaces for you." |
80 |
> |
81 |
> From: |
82 |
> |
83 |
> http://www.freedesktop.org/wiki/Software/systemd/journal-files/ |
84 |
> |
85 |
> Wow, that makes me feel all warm, fuzzy and secure as shit. I think I |
86 |
> just fell asleep for a moment. (My background would make me read this, |
87 |
> essentially advertising copy, as a classic example of perverse use of |
88 |
> semiotics, thus raising the reading on my B.S. meter. But I digress.) |
89 |
> |
90 |
> The best part is the conclusion: |
91 |
> |
92 |
> *If you find a limitation, please ping us and we might add some |
93 |
> additional interfaces for you.* |
94 |
> |
95 |
> Please! Ping! |
96 |
> |
97 |
> Second best is, "we'll of course try hard to keep this document |
98 |
> up-to-date and accurate". Of course. |
99 |
> |
100 |
> So. If I were paranoid, or even mildly concerned, I'd take this to mean |
101 |
> two things: |
102 |
> |
103 |
> One. There is, or could be, data that the systemd logging magic box |
104 |
> doesn't give you an interface for. Unless you know what it is, then |
105 |
> they might let you log it. Or you can, of course, contribute code, I'm |
106 |
> sure. Though, "Note that the actual implementation in the systemd |
107 |
> codebase is the only ultimately authoritative description of the |
108 |
> format". |
109 |
> |
110 |
> Two. If I want to have a reasonable degree of surety that the code |
111 |
> isn't collecting data that isn't interfaced for you in the |
112 |
> journalcontrol, I'd have to delve into the codebase for systemd. Which, |
113 |
> I'm sure, is a piece of cake. And, of course, I, and my security team, |
114 |
> have to review the basic code on my GNU/Linux F[L]OSS machine regularly |
115 |
> anyway. |
116 |
> |
117 |
> Oh, wait... No I don't. |
118 |
> |
119 |
> The beauty of the development model I trust is a diverse group of folks |
120 |
> with a *variety of interests* contributing to various areas of code, in |
121 |
> turn reviewed by some set of that same varied group, eventually |
122 |
> committed and merged rolled tested in the wild. |
123 |
> |
124 |
> Or however you may see the ideal (or fantasy) of the ecosystem as we |
125 |
> know, or knew it. |
126 |
> |
127 |
> Just the comment in this other related thread, systemd deprecating a |
128 |
> straightforward encryption setup in version N, what is next? |
129 |
> |
130 |
> Okay, I'll go re-wire my tin hat now. Hope someone found this amusing. |
131 |
|
132 |
Since you beat a lot around the bush, I will try to answer to (what I |
133 |
believe is) your main point. |
134 |
|
135 |
Take a look at [1]. That's all the code from the journal. |
136 |
|
137 |
The format the journal uses to store its logs its binary. There is no |
138 |
grand conspiracy behind this; it's simply the fact that it wants the |
139 |
logs indexed so it can search by key on O(log n) time, instead of O(n) |
140 |
like the regular logs from all the family of syslog. It also compress |
141 |
them while at it. |
142 |
|
143 |
The format is binary; but the code to read it (and write it) is not, |
144 |
and is available for everyone to see. Again, take a look at [1]. |
145 |
|
146 |
You can see the hate systemd generates around. A lot of people are |
147 |
keeping an eye on it, looking for things to criticize. At the first |
148 |
moment something fishy got into the journal source code (like your |
149 |
mail seems to imply is possible), those watchers would howl like there |
150 |
is no tomorrow. The fact that this hasn't happened is the most simple |
151 |
proof that there is no grand conspiracy. |
152 |
|
153 |
You don't believe on the collective eyes of the Linux community? OK, |
154 |
then *you* take a look trying to find something fishy; everything is |
155 |
done in the open: again, take a look at [1]. |
156 |
|
157 |
You don't have the necessary abilities to determine if there is |
158 |
something fishy going on them? Then pay someone to do the analysis for |
159 |
you; it's probably what Intel, AMD, IBM, Oracle, Valve, and other |
160 |
companies that have a deep interest in seeing that Linux remain |
161 |
independent of any single entity have been doing all the time since |
162 |
systemd (and other core technologies) have appeared. |
163 |
|
164 |
But I'm going to save you some bucks: there is nothing fishy. |
165 |
|
166 |
Carry on with the wires on the tin hat. |
167 |
|
168 |
Regards. |
169 |
|
170 |
[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/journal |
171 |
-- |
172 |
Canek Peláez Valdés |
173 |
Posgrado en Ciencia e Ingeniería de la Computación |
174 |
Universidad Nacional Autónoma de México |