1 |
Alex know I love and respect your opinion but with you being mostly gone |
2 |
and my own business starting is suffering due to the large amount of |
3 |
time the project takes I'm not seeing a whole lot of alternatives unless |
4 |
we get some help from some hard hitters. |
5 |
|
6 |
Yes we could leave the patches in and _hope_ that things continue to |
7 |
work. But who is going to watch the bugs and verify that something is |
8 |
not a flaw in our own design? how do we deal with fundamental design |
9 |
flaws with upstream security patches when they don't care? (I know you |
10 |
know this one all to well) example |
11 |
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132149 |
12 |
|
13 |
Where is our core documentation? Where is the comparative analysis of |
14 |
security measures? Who is going to maintain our appropriate profiles? |
15 |
Keeping up with virtuals is nearly a task in and of itself. Rolling |
16 |
stages and working towards things like livecd's. These are fundamental |
17 |
things that have to be done on a cycles that follow gentoo mainline. how |
18 |
about aiming for getting some of these solutions to go gentoo mainline. |
19 |
All suids and daemons for example should really be compiled the way we |
20 |
do. But that's an uphill battle that I'm pretty sure I don't want to try |
21 |
to tackle alone. |
22 |
|
23 |
I see things like users that have completely uninstalled the |
24 |
hardened-toolchain to work around small bugs when they don't have to. I |
25 |
can't comment on every bug to say here is another way you can get the |
26 |
same end goal without them having to dismiss the solution completely, be |
27 |
that their own ignorance or ours it's a disservice to our community do |
28 |
nothing. |
29 |
|
30 |
Being on this team means more than just watching the "hardened" bugs |
31 |
that get routed to us and replying to emails once every few weeks, one |
32 |
has to watch all toolchain bugs and look for how things correlate to |
33 |
each other and determine the right thing to do. |
34 |
|
35 |
Other distro's are wanting to adopt similar to the same solution but |
36 |
those guys need to be helped so they don't make fatal mistakes. Yes it's |
37 |
a very good sign when others want to adopt it. But that's also time |
38 |
consuming. Ask yourself should we keep our dear precious all to |
39 |
ourselves or dedicate some time and effort to other projects of the |
40 |
world. I think we should as most of these designs are being developed in |
41 |
house and we by far have the most experience. |
42 |
See http://d-sbd.alioth.debian.org/ for more details. |
43 |
|
44 |
How are we going to handle the other arches. |
45 |
ppc/ppc64 These two arches could be added to mix relatively easy. But |
46 |
**** we can't even get one of those teams to test simple kernel patches |
47 |
that were developed especially for them after multiple requests. |
48 |
|
49 |
Peter has many questions that he needs definitive answers to. With those |
50 |
questions going unanswered and him being a key player these days in your |
51 |
absence we could be potentially introducing more bugs than need be. |
52 |
He is/was happy with his own homegrown build system and does not really |
53 |
need to support us or our efforts. |
54 |
|
55 |
You want to help pappy? Spend your time being proactive vs defensive. |
56 |
Help me train some people so the workload is reduced on us and our time |
57 |
can be better spent focusing on making the next steps with more ease. |
58 |
|
59 |
After planting the initial seeds one day and seeing things being |
60 |
maintained properly long term I'd like to be just a user ya know. |
61 |
|
62 |
On Sat, 2004-09-18 at 11:54, Alexander Gabert wrote: |
63 |
> Ned Ludd wrote: |
64 |
> |
65 |
> > I really never wanted to send a mail like this but I don't know what |
66 |
> > else to do. ;/ |
67 |
> > |
68 |
> > Due to low positive feedback and user input I'm considering dropping |
69 |
> > the hardened toolchain |
70 |
> |
71 |
> Sat Sep 18 16:14:04 CEST 2004 |
72 |
> |
73 |
> Subject: A Quantitive Approach |
74 |
> |
75 |
> Dear Solar, |
76 |
> |
77 |
> it does not surprise me that you are proposing a "change for the better" |
78 |
> with |
79 |
> dismissing the hardened toolchain. |
80 |
> |
81 |
> But you should think about the impact. |
82 |
> |
83 |
> Does the solution itself offer such poor quality that it should not/cannot |
84 |
> survive? |
85 |
> |
86 |
> I think you are forgetting about one more important fact than unfixed bugs. |
87 |
> I know that these bugs are mainly existing due to low manpower, |
88 |
> which is also majorily my fault because i promised to commit to |
89 |
> the solution in the past and did not deliver a considerable amount of |
90 |
> time and |
91 |
> work to fulfill my responsibilities at the Gentoo Hardened team. |
92 |
> |
93 |
> But before you are starting to put solutions to an end of life, i would like |
94 |
> you to consider the benefits and the misunderstandings from a more |
95 |
> "objective" |
96 |
> point of view: |
97 |
> |
98 |
> When a beginner starts using the hardened toolchain (which is not what |
99 |
> it was |
100 |
> designed for), he or she will immediately suffer from deep impacts of our |
101 |
> "evil" compiler modifications. |
102 |
> |
103 |
> We create documentation as easy as possible to make the "entry point" to the |
104 |
> solution low. But that does not mean an ape with a joystick can fly a |
105 |
> rocket. |
106 |
> |
107 |
> You have to follow me on the thought that if someone with a professional |
108 |
> attitude |
109 |
> will see bugs and make up his/her own mind about those bugs with a |
110 |
> certain degree |
111 |
> of understanding what is going on, he or she is going to find the cause and |
112 |
> report it back to us without stupid comments like "your shit does not work" |
113 |
> (which is not a quote from a bug but what comes into my mind when i read |
114 |
> many |
115 |
> bugs, and yes, i read them) |
116 |
> |
117 |
> We give the tools- the people use it. Thats the game, that is how it |
118 |
> always has been. |
119 |
> We make things easy. But we cannot make things so foolproof that you cannot |
120 |
> cut your throat with it. |
121 |
> |
122 |
> With compilers and toolchains its different than with media players or name |
123 |
> servers. Either a media player works or it plays videos too fast or does |
124 |
> nothing- like my mplayer does sometimes. People open bugs about mplayer. |
125 |
> |
126 |
> What people expect from mplayer is that it plays video. |
127 |
> |
128 |
> What security people expect from a hardened toolchain is that it compiles |
129 |
> software in a defined and security-oriented fashion. |
130 |
> |
131 |
> Peter Mazinger is working very hard and he is successfully delivering |
132 |
> the needed compiler modifications. |
133 |
> The PaX patch, provided by the PaX team, is the dark eminence (i.e. kernel) |
134 |
> behind the scenes that makes the things work as expected (and defined). |
135 |
> |
136 |
> What are the reasons that you want to postpone those two cornerstones of |
137 |
> basic |
138 |
> security improvements over default userland and default linux kernel? |
139 |
> |
140 |
> Do you call it a "failed experiment"? No. |
141 |
> |
142 |
> You are just telling people to get up and support it or you will cancel it. |
143 |
> |
144 |
> As a project manager for the toolchain you can order your developers to |
145 |
> get up |
146 |
> to date with open patches and take care of the user base. You are right. |
147 |
> |
148 |
> But what user base and feedback do you expect? |
149 |
> |
150 |
> The people using it do not file bugs, because they understand that |
151 |
> |
152 |
> a) using bleeding edge software may/can break shit |
153 |
> |
154 |
> b) using hardened toolchain to emerge (from a security perspective) |
155 |
> unneeded stuff can break more shit |
156 |
> |
157 |
> Who said that the hardened toolchain can be blamed for people using it, |
158 |
> compiling |
159 |
> their desktop machines and after that joining the #channel and/or |
160 |
> opening bugs |
161 |
> without a slight degree (or as a matter of fact: interest) in |
162 |
> understanding or even |
163 |
> WORKING with the solution. |
164 |
> |
165 |
> Normally, people open bugs to get something fixed. |
166 |
> But face it: mplayer will not be fixed. |
167 |
> |
168 |
> Do you think i am proud of the bugs? You know that i am not and i know that |
169 |
> it hurts you to see our stuff getting so "dissed". |
170 |
> |
171 |
> Trust me, they all want "security out of the box" and maybe our |
172 |
> documentation is misleading |
173 |
> and trying to "promise" that in a way. But it is not wrong, the |
174 |
> documentation. |
175 |
> |
176 |
> Lets go somewhere else because i was discussing "low entry level" and |
177 |
> USE flags |
178 |
> for ease of customer experience already above. |
179 |
> |
180 |
> We started this project as pioneers. Now we are experienced users of |
181 |
> our own |
182 |
> solution. |
183 |
> |
184 |
> When people were asking me for "full scope" coverage of the hardened |
185 |
> solution |
186 |
> for the full Gentoo userland, it took me a very long time to think about |
187 |
> possible ways for making "transparent" defuse switches. |
188 |
> |
189 |
> Then i said: it can be done, but only with my tricks. My tricks have |
190 |
> not been |
191 |
> accepted by the developers (see discussions on public lists) and i |
192 |
> agreed that |
193 |
> it was not possible without losing important factors like "visibility" of |
194 |
> changes and "reproducability" of toolchain and compilers involved. |
195 |
> |
196 |
> But those problems arising now were created by a simple mathematical |
197 |
> function: |
198 |
> |
199 |
> Ignorance * People * Time / Commitment to the Solution = number of open |
200 |
> bugs. |
201 |
> |
202 |
> If the commitment to the solution by the people opening bugs were high |
203 |
> enough |
204 |
> to "keep it going", we would not have to bother about too much "ignorance |
205 |
> bugs". I know this sounds harsh. |
206 |
> |
207 |
> And it does not mean to "insult" our customers and users. But face it. |
208 |
> |
209 |
> If ignorance were near zero, this equation would hold our bug level nice |
210 |
> and low. |
211 |
> But it does not. |
212 |
> |
213 |
> If the number of people were low, it would also be nice and low. |
214 |
> |
215 |
> If the time had not shown the major deficiencies (which the solution clearly |
216 |
> has), it would also not have become such an imminent point of "turning |
217 |
> around" |
218 |
> now. |
219 |
> |
220 |
> You are asking what to do. I think that is just fair because it shows your |
221 |
> community spirit, your true efforts and your heart for the solution and the |
222 |
> Gentoo team. |
223 |
> |
224 |
> You don't want anybody to blame us for letting people wrestle in the mud |
225 |
> of a |
226 |
> "broken" hardened toolchain "solution". |
227 |
> |
228 |
> But as is said before: this is a team of volunteers- and volunteers means: |
229 |
> people "sacrifice" their free time for the project and the ongoing |
230 |
> quality of |
231 |
> the project. |
232 |
> |
233 |
> If quality is low, it does not mean that the developers are stubborn fools. |
234 |
> |
235 |
> To give another mathematical example: |
236 |
> |
237 |
> free time * commitment = quality. |
238 |
> |
239 |
> If free time is low (which has been the case in my personal situation), the |
240 |
> quality cannot be high. |
241 |
> |
242 |
> And i also know that you never suspected the commitment of team members |
243 |
> to be |
244 |
> under a needed level that the solution can "go on". |
245 |
> |
246 |
> When you say: "dropping the hardened toolchain", to me it sounds like "stop |
247 |
> riding a dead horse". |
248 |
> |
249 |
> But, in my eyes, you are underestimating the negative impact of that |
250 |
> decision on people |
251 |
> successfully using the solution. |
252 |
> |
253 |
> Do you need success stories for letting it continue? |
254 |
> Do you need mails of people that tell you: good job, things broke left and |
255 |
> right of me, but i am a proud owner of a hardened gcc. |
256 |
> |
257 |
> You and me know that you will never get such mails. |
258 |
> |
259 |
> People do not bother. They only bitch and whine when it breaks and the |
260 |
> house |
261 |
> is burning down because they have been playing with the dynamite and at the |
262 |
> same time forgot the lit cigarette in their mouth. |
263 |
> |
264 |
> This is what you have been doing in the last weeks: collecting examples of |
265 |
> "bad feedback". |
266 |
> |
267 |
> And you can declare the "low positive" feedback as that any "high positive" |
268 |
> feedback does not exist. Of course it does not- reason is above. |
269 |
> |
270 |
> |
271 |
> Does the "large" userbase really "ad hoc" enable the hardened USE flag and |
272 |
> then loads of workstations go down the drain and bugs.gentoo.org suffers |
273 |
> major |
274 |
> headache from people opening hundreds of duplicate bug requests? |
275 |
> |
276 |
> If you are comparing the negative impact of hardened gcc to the "mistakes" |
277 |
> made by some glibc and gcc updates in the past, i cannot see a reason why a |
278 |
> "large user base" that is reluctant to work with us and find solutions |
279 |
> should |
280 |
> be a reason for us to "retreat" from our positions of zero tolerance towards |
281 |
> high security systems- this includes kernel, compilers and other tools like |
282 |
> full runtime bounds checking (remember that the libmudflap source again |
283 |
> did not |
284 |
> make it to mainstream gcc). |
285 |
> |
286 |
> To be honest, your approach is too simple. |
287 |
> |
288 |
> You say: it does not work, lets drop it |
289 |
> |
290 |
> I say: WORKSFORME |
291 |
> |
292 |
> Peter Mazinger is putting big efforts in creating patches. |
293 |
> The PaX kernel can go to its full strength on a Gentoo Hardened system. |
294 |
> |
295 |
> |
296 |
> It takes people who think to implement security. |
297 |
> |
298 |
> We give the tools. |
299 |
> |
300 |
> People use tools. Did you know that you can cut your throat with a |
301 |
> screwdriver? I do not remember seeing warnings on screwdriver not to |
302 |
> cut your |
303 |
> throat while operating it. |
304 |
> |
305 |
> We cannot be personally held responsible (or liable) for the ignorance of |
306 |
> people who want "security out of the box". |
307 |
> |
308 |
> See you at the bitter end, |
309 |
> |
310 |
> Alex |
311 |
> |
312 |
> (And yes, this all could have been said with less than one quarter of the |
313 |
> character count, but i was in the mood of defensive arguments ;-) |
314 |
-- |
315 |
Ned Ludd <solar@g.o> |
316 |
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer |