1 |
On Thursday 03 August 2006 04:56, Brian Harring wrote: |
2 |
> *cough*. bit hypocritical for you to lecture me about viewing |
3 |
> your statements as 'flaming', and in the same breath label |
4 |
> my own as 'flaming' ;) |
5 |
> |
6 |
> Why am I pointing this out? My initial points were that of "why the |
7 |
> double standard", with you providing an apt example (while that's |
8 |
> barbed, you did provide a perfect refresher of the definition). |
9 |
|
10 |
The difference is that I argue, while you accuse me to play false. I consider |
11 |
this as ad hominem and together with all this "FUD" and "BS" calling, in |
12 |
contrary to my email, inflammatory. |
13 |
|
14 |
|
15 |
> > I'd appreciate, if you would try to have a controversial |
16 |
> > discussion, without starting to loose your manners. |
17 |
> |
18 |
> And I'd appreciate a less condescending tone. |
19 |
|
20 |
This wasn't meant condescending, but a true request. Because it's not the |
21 |
first time you react this way, when you dislike another ones opinion. It is |
22 |
as annoying as Ciaran's habit to make statements without backing them up - |
23 |
even when asked to do so. |
24 |
|
25 |
|
26 |
> You wrote 'no security'. That's pretty fricking vague, can cover |
27 |
> everything from no verification of sync'd contents, to their vcs |
28 |
> security, to their screening processes, to vulns in their packages. |
29 |
|
30 |
I wrote that you should read my replies in the initial thread. |
31 |
|
32 |
|
33 |
> If you wanted to home in vulns in the source (which isn't security as |
34 |
> much as 'vulnerabilities in the source'), be explicit. |
35 |
|
36 |
I was. |
37 |
|
38 |
|
39 |
> Now on to the real points (yay)... |
40 |
> |
41 |
> > My point isn't that |
42 |
> > people add malicious ebuilds to the overlay. There're more subtle methods |
43 |
> > anyway, given that the tree still isn't signed. I wrote about |
44 |
> > vulnerablities in the upstream software, neither having a security team |
45 |
> > backing them up nor GLSA's to be written. |
46 |
> |
47 |
> 1) same issue with the ebuilds sitting in bugzilla, going to hunt |
48 |
> through bugzie marking each submitted ebuild when a security bug hits? |
49 |
> |
50 |
> 2) Response to that is that "there is no claim of support"- which is |
51 |
> the same for sunrise. Why are the rules different for sunrise then? |
52 |
|
53 |
The difference is that people are using them in their local overlay and |
54 |
therefore - in contrary to the Sunrise overlay - a) are only exposed to the |
55 |
packges they _really_ want to use and b) are responsible for it themselves. |
56 |
|
57 |
Aside of this I might add that I do add comments to bug reports, when I |
58 |
stumble about vulnerability notices and find relevant bug reports. |
59 |
|
60 |
|
61 |
> 3) Assumption that sunrise will just be a dumping ground, without any |
62 |
> form of maintainance is implicit here- if it becomes as such, already |
63 |
> was stated it would get wedgied by the council. So that leaves the |
64 |
> angle of "they don't have a security team", which implies to actually |
65 |
> handle nuking vulnerable ebuilds, one has to have a security team |
66 |
> (obviously false). |
67 |
|
68 |
Dumping ground or not. It's easy to miss vulnerability notices. Especially, if |
69 |
you don't have guys who expclicitly care for it. And you need a security team |
70 |
to announce issue to the user base. I wouldn't use Gentoo, if we not had such |
71 |
a hard and good working security team. |
72 |
|
73 |
|
74 |
> Besides... frankly it's kind of BS to push the vuln angle onto sunrise |
75 |
> when gentoo can't even clean out years old vulnerable packages from |
76 |
> gentoo-x86 (that doesn't absolve sunrise from having to watch it, nor |
77 |
> a potshot at the understaffed security team, merely that double |
78 |
> standards suck). |
79 |
|
80 |
Interesting to see you state this. Because this is a far more serious problem, |
81 |
than supporting "everything" possible; And Sunrise won't fix this either - if |
82 |
not the opposite. One of the goals of Sunrise is to recruit new devs. But we |
83 |
don't need new devs to add new packages primarily, we more to maintain |
84 |
existing and not so fancy stuff and to clean out the tree. |
85 |
|
86 |
|
87 |
> You want to set a standard for 'em, fine, lets use the standard of the |
88 |
> existing tree when compared to existing glsas- note that there may be |
89 |
> vulns that gentoo doesn't have glsas for, or vulns that are in the |
90 |
> security pipeline and haven't yet been issued as a glsa (since gentoo |
91 |
> issues it after porting). |
92 |
> |
93 |
> 285 versions out of 24637 vulnerable (~1 out of every 86 vuln) |
94 |
> 115 packages out of 11251 vulnreable (~1 out of every 98 vuln) |
95 |
> |
96 |
> http://gentooexperimental.org/~ferringb/vuln.log |
97 |
> |
98 |
> So... if that's the standard you want to hold them to, fine, state |
99 |
> so- they may agree to it (although admittedly such a standard is |
100 |
> stupid, there should be _no_ vuln packages). |
101 |
|
102 |
Your list is rubbish. There're stable versions for all security wise supported |
103 |
architectures and the relevant GLSA's. If users don't use them, it's their |
104 |
local problem. |
105 |
|
106 |
|
107 |
> > > And... just cause I'm mildly sick of this bullshit, |
108 |
> > |
109 |
> > And I'm sick of people, who miss the point. |
110 |
> |
111 |
> As stated above, be concise then. Your points came out of pretty |
112 |
> much nowhere, poorly communicated, and rather vague in actually |
113 |
> backing them up. Which... at least from the "backing up the |
114 |
> complaints", has been the theme for the screaming folk thus far. |
115 |
|
116 |
Do I have to learn you to read? See above. |
117 |
|
118 |
|
119 |
> > We can change eclasses all the time, assuming all relevant ebuilds in the |
120 |
> > tree get adjusted - just that no one cares for any overlay. |
121 |
> |
122 |
> No, actually you cannot. |
123 |
> |
124 |
> Just because you update the tree doesn't mean you're not going and |
125 |
> breaking binpkgs, or the vdb installation. |
126 |
> |
127 |
> Read glep33 if you want the sordid back history and solution to it. |
128 |
> |
129 |
> Like I said, y'all violate it, doesn't mean it's right. |
130 |
|
131 |
Is that a joke or what? I do support GLEP 33, but it's not implemented yet. |
132 |
Also I can change eclasses in many ways breaking third party ebuilds, but not |
133 |
binary packages. That aside, relying on binary packages without taking a |
134 |
snapshot of the tree is rather brave. Gentoo is a more or less dynamic source |
135 |
distribution and there is no ensurance binary packages will work "forever". |
136 |
|
137 |
|
138 |
> > Local overlays are fine as the user exactly knows what he does in his |
139 |
> > private overlay (and hopefully follows eclass changes), development |
140 |
> > overlays are fine (assuming the group of people controls the releavant |
141 |
> > overlays as well), overlays like Sunrise are problematic, not to use such |
142 |
> > anal words as you do. |
143 |
> |
144 |
> Why are they problematic? Because of your assumption that they won't |
145 |
> maintain it? |
146 |
|
147 |
As I said: Security issue, eclass incompatiblities. Want another example? Here |
148 |
it is: What if you have packges that need to block each other (usually |
149 |
because of installing the same files). Mutual cross overlay blockers? Forget |
150 |
it. |
151 |
|
152 |
|
153 |
> So someone goes and breaks something in gentoo-x86 that breaks |
154 |
> something for sunrise. Fine, it's sunrises' mess to clean up; they've |
155 |
> volunteered to do this work, I don't see how you can claim it as a |
156 |
> negative when they've accepted it as part of _their_ work. |
157 |
|
158 |
The problems will pile up in bugs.g.o and "usally" with the wrong addressee. |
159 |
This has been every now and then the case with other overlays as well as |
160 |
users of distros building on Gentoo. I can live with that to a degree. But |
161 |
when we do this mess ourselves, it get's highly annoying. |
162 |
|
163 |
|
164 |
> Worth noting sunrise folk may be gentoo devs also- and as stated |
165 |
> above, they're trying to extend beyond gentoo-x86; it's not like |
166 |
> they're demanding you do things their way- far from it, it's actually |
167 |
> the reverse, devs demanding things of sunrise. You break their shit, |
168 |
> they'll fix it (it's the nature of this relationship, even though it |
169 |
> should be _cooperative_ instead of "get lost" that seems to be the |
170 |
> norm now). |
171 |
> |
172 |
> So again... how is this a negative? It's *their* damn time- if you |
173 |
> wanted to be an ass and go break their stuff, as retarded as it is you |
174 |
> _could_ because they stepped up for the job. |
175 |
|
176 |
I have answered all that above. |
177 |
|
178 |
|
179 |
> Granted, they may give you the finger and quit, or your remaining |
180 |
> fellow devs may rightfully boot you for playing games, but the point |
181 |
> stands- they stepped up to do the work, including cleaning up |
182 |
> anything y'all may break for them. |
183 |
|
184 |
You're doing it again. No I'm not playig games with you. I have reasonable |
185 |
complaints and consider this sort of overlay a failure. Then an extra |
186 |
development tree would be much better. |
187 |
|
188 |
|
189 |
> You're not limited- they're the ones limited via trying to not step on |
190 |
> gentoo-x86's toes. How is that a negative then? |
191 |
|
192 |
I fear for the security of our user base, especially the lazy, uneducated |
193 |
ricers and how this wll reflect on Gentoo's reputation as a whole. I fear |
194 |
more annoying, invalid bug reports. I don't see any benefit for the existing |
195 |
tree or Gentoo as a whole. |
196 |
|
197 |
|
198 |
Carsten |