Gentoo Archives: gentoo-dev

From: Alexander Gabert <pappy@g.o>
To: solar@g.o
Cc: gentoo-hardened@l.g.o, gentoo-dev@l.g.o, ps.m@×××.net, pageexec@××××××××.hu
Subject: Re: [gentoo-dev] Considering dropping the hardened toolchain (A Quantitive Approach)
Date: Sat, 18 Sep 2004 15:54:49
Message-Id: 414C5A1E.4030808@gentoo.org
In Reply to: [gentoo-dev] Considering dropping the hardened toolchain by Ned Ludd
1 Ned Ludd wrote:
2
3 > I really never wanted to send a mail like this but I don't know what
4 > else to do. ;/
5 >
6 > Due to low positive feedback and user input I'm considering dropping
7 > the hardened toolchain
8
9 Sat Sep 18 16:14:04 CEST 2004
10
11 Subject: A Quantitive Approach
12
13 Dear Solar,
14
15 it does not surprise me that you are proposing a "change for the better"
16 with
17 dismissing the hardened toolchain.
18
19 But you should think about the impact.
20
21 Does the solution itself offer such poor quality that it should not/cannot
22 survive?
23
24 I think you are forgetting about one more important fact than unfixed bugs.
25 I know that these bugs are mainly existing due to low manpower,
26 which is also majorily my fault because i promised to commit to
27 the solution in the past and did not deliver a considerable amount of
28 time and
29 work to fulfill my responsibilities at the Gentoo Hardened team.
30
31 But before you are starting to put solutions to an end of life, i would like
32 you to consider the benefits and the misunderstandings from a more
33 "objective"
34 point of view:
35
36 When a beginner starts using the hardened toolchain (which is not what
37 it was
38 designed for), he or she will immediately suffer from deep impacts of our
39 "evil" compiler modifications.
40
41 We create documentation as easy as possible to make the "entry point" to the
42 solution low. But that does not mean an ape with a joystick can fly a
43 rocket.
44
45 You have to follow me on the thought that if someone with a professional
46 attitude
47 will see bugs and make up his/her own mind about those bugs with a
48 certain degree
49 of understanding what is going on, he or she is going to find the cause and
50 report it back to us without stupid comments like "your shit does not work"
51 (which is not a quote from a bug but what comes into my mind when i read
52 many
53 bugs, and yes, i read them)
54
55 We give the tools- the people use it. Thats the game, that is how it
56 always has been.
57 We make things easy. But we cannot make things so foolproof that you cannot
58 cut your throat with it.
59
60 With compilers and toolchains its different than with media players or name
61 servers. Either a media player works or it plays videos too fast or does
62 nothing- like my mplayer does sometimes. People open bugs about mplayer.
63
64 What people expect from mplayer is that it plays video.
65
66 What security people expect from a hardened toolchain is that it compiles
67 software in a defined and security-oriented fashion.
68
69 Peter Mazinger is working very hard and he is successfully delivering
70 the needed compiler modifications.
71 The PaX patch, provided by the PaX team, is the dark eminence (i.e. kernel)
72 behind the scenes that makes the things work as expected (and defined).
73
74 What are the reasons that you want to postpone those two cornerstones of
75 basic
76 security improvements over default userland and default linux kernel?
77
78 Do you call it a "failed experiment"? No.
79
80 You are just telling people to get up and support it or you will cancel it.
81
82 As a project manager for the toolchain you can order your developers to
83 get up
84 to date with open patches and take care of the user base. You are right.
85
86 But what user base and feedback do you expect?
87
88 The people using it do not file bugs, because they understand that
89
90 a) using bleeding edge software may/can break shit
91
92 b) using hardened toolchain to emerge (from a security perspective)
93 unneeded stuff can break more shit
94
95 Who said that the hardened toolchain can be blamed for people using it,
96 compiling
97 their desktop machines and after that joining the #channel and/or
98 opening bugs
99 without a slight degree (or as a matter of fact: interest) in
100 understanding or even
101 WORKING with the solution.
102
103 Normally, people open bugs to get something fixed.
104 But face it: mplayer will not be fixed.
105
106 Do you think i am proud of the bugs? You know that i am not and i know that
107 it hurts you to see our stuff getting so "dissed".
108
109 Trust me, they all want "security out of the box" and maybe our
110 documentation is misleading
111 and trying to "promise" that in a way. But it is not wrong, the
112 documentation.
113
114 Lets go somewhere else because i was discussing "low entry level" and
115 USE flags
116 for ease of customer experience already above.
117
118 We started this project as pioneers. Now we are experienced users of
119 our own
120 solution.
121
122 When people were asking me for "full scope" coverage of the hardened
123 solution
124 for the full Gentoo userland, it took me a very long time to think about
125 possible ways for making "transparent" defuse switches.
126
127 Then i said: it can be done, but only with my tricks. My tricks have
128 not been
129 accepted by the developers (see discussions on public lists) and i
130 agreed that
131 it was not possible without losing important factors like "visibility" of
132 changes and "reproducability" of toolchain and compilers involved.
133
134 But those problems arising now were created by a simple mathematical
135 function:
136
137 Ignorance * People * Time / Commitment to the Solution = number of open
138 bugs.
139
140 If the commitment to the solution by the people opening bugs were high
141 enough
142 to "keep it going", we would not have to bother about too much "ignorance
143 bugs". I know this sounds harsh.
144
145 And it does not mean to "insult" our customers and users. But face it.
146
147 If ignorance were near zero, this equation would hold our bug level nice
148 and low.
149 But it does not.
150
151 If the number of people were low, it would also be nice and low.
152
153 If the time had not shown the major deficiencies (which the solution clearly
154 has), it would also not have become such an imminent point of "turning
155 around"
156 now.
157
158 You are asking what to do. I think that is just fair because it shows your
159 community spirit, your true efforts and your heart for the solution and the
160 Gentoo team.
161
162 You don't want anybody to blame us for letting people wrestle in the mud
163 of a
164 "broken" hardened toolchain "solution".
165
166 But as is said before: this is a team of volunteers- and volunteers means:
167 people "sacrifice" their free time for the project and the ongoing
168 quality of
169 the project.
170
171 If quality is low, it does not mean that the developers are stubborn fools.
172
173 To give another mathematical example:
174
175 free time * commitment = quality.
176
177 If free time is low (which has been the case in my personal situation), the
178 quality cannot be high.
179
180 And i also know that you never suspected the commitment of team members
181 to be
182 under a needed level that the solution can "go on".
183
184 When you say: "dropping the hardened toolchain", to me it sounds like "stop
185 riding a dead horse".
186
187 But, in my eyes, you are underestimating the negative impact of that
188 decision on people
189 successfully using the solution.
190
191 Do you need success stories for letting it continue?
192 Do you need mails of people that tell you: good job, things broke left and
193 right of me, but i am a proud owner of a hardened gcc.
194
195 You and me know that you will never get such mails.
196
197 People do not bother. They only bitch and whine when it breaks and the
198 house
199 is burning down because they have been playing with the dynamite and at the
200 same time forgot the lit cigarette in their mouth.
201
202 This is what you have been doing in the last weeks: collecting examples of
203 "bad feedback".
204
205 And you can declare the "low positive" feedback as that any "high positive"
206 feedback does not exist. Of course it does not- reason is above.
207
208
209 Does the "large" userbase really "ad hoc" enable the hardened USE flag and
210 then loads of workstations go down the drain and bugs.gentoo.org suffers
211 major
212 headache from people opening hundreds of duplicate bug requests?
213
214 If you are comparing the negative impact of hardened gcc to the "mistakes"
215 made by some glibc and gcc updates in the past, i cannot see a reason why a
216 "large user base" that is reluctant to work with us and find solutions
217 should
218 be a reason for us to "retreat" from our positions of zero tolerance towards
219 high security systems- this includes kernel, compilers and other tools like
220 full runtime bounds checking (remember that the libmudflap source again
221 did not
222 make it to mainstream gcc).
223
224 To be honest, your approach is too simple.
225
226 You say: it does not work, lets drop it
227
228 I say: WORKSFORME
229
230 Peter Mazinger is putting big efforts in creating patches.
231 The PaX kernel can go to its full strength on a Gentoo Hardened system.
232
233
234 It takes people who think to implement security.
235
236 We give the tools.
237
238 People use tools. Did you know that you can cut your throat with a
239 screwdriver? I do not remember seeing warnings on screwdriver not to
240 cut your
241 throat while operating it.
242
243 We cannot be personally held responsible (or liable) for the ignorance of
244 people who want "security out of the box".
245
246 See you at the bitter end,
247
248 Alex
249
250 (And yes, this all could have been said with less than one quarter of the
251 character count, but i was in the mood of defensive arguments ;-)
252
253
254
255 --
256 gentoo-dev@g.o mailing list

Replies