On Wed, Aug 02, 2006 at 08:05:15PM +0200, Carsten Lohrke wrote: > First I'd like to state that I do offer my opinion. You don't have to like > it, > but disqualifying it as flaming, while exactly doing this yourself, > disqualifies you.
*cough*. bit hypocritical for you to lecture me about viewing your statements as 'flaming', and in the same breath label my own as 'flaming' ;) Why am I pointing this out? My initial points were that of "why the double standard", with you providing an apt example (while that's barbed, you did provide a perfect refresher of the definition). > I'd appreciate, if you would try to have a controversial > discussion, without starting to loose your manners. And I'd appreciate a less condescending tone. > On Wednesday 02 August 2006 03:39, Brian Harring wrote: > > 1) no security, > > > > Suggest you read their responses, and look into some of their material > > (in particular their faq). > > > > Two levels. > > > > One, holding area (essentially). > > Second level (what users get), is the reviewed branch. > > > > So... if you're arguing people can stick malicious shit into the first > > level, yes, they could. > > [...] > > You haven't read what I wrote, as I asked you to do. You wrote 'no security'. That's pretty fricking vague, can cover everything from no verification of sync'd contents, to their vcs security, to their screening processes, to vulns in their packages. If you wanted to home in vulns in the source (which isn't security as much as 'vulnerabilities in the source'), be explicit. Now on to the real points (yay)... > My point isn't that > people add malicious ebuilds to the overlay. There're more subtle methods > anyway, given that the tree still isn't signed. I wrote about vulnerablities > in the upstream software, neither having a security team backing them up nor > GLSA's to be written. 1) same issue with the ebuilds sitting in bugzilla, going to hunt through bugzie marking each submitted ebuild when a security bug hits? 2) Response to that is that "there is no claim of support"- which is the same for sunrise. Why are the rules different for sunrise then? 3) Assumption that sunrise will just be a dumping ground, without any form of maintainance is implicit here- if it becomes as such, already was stated it would get wedgied by the council. So that leaves the angle of "they don't have a security team", which implies to actually handle nuking vulnerable ebuilds, one has to have a security team (obviously false). Besides... frankly it's kind of BS to push the vuln angle onto sunrise when gentoo can't even clean out years old vulnerable packages from gentoo-x86 (that doesn't absolve sunrise from having to watch it, nor a potshot at the understaffed security team, merely that double standards suck). You want to set a standard for 'em, fine, lets use the standard of the existing tree when compared to existing glsas- note that there may be vulns that gentoo doesn't have glsas for, or vulns that are in the security pipeline and haven't yet been issued as a glsa (since gentoo issues it after porting). 285 versions out of 24637 vulnerable (~1 out of every 86 vuln) 115 packages out of 11251 vulnreable (~1 out of every 98 vuln) http://gentooexperimental.org/~ferringb/vuln.log So... if that's the standard you want to hold them to, fine, state so- they may agree to it (although admittedly such a standard is stupid, there should be _no_ vuln packages). Don't automatically assume they'll be worse however, let alone assume that gentoo-x86 is perfect (again, no double standards). > > And... just cause I'm mildly sick of this bullshit, > > And I'm sick of people, who miss the point. As stated above, be concise then. Your points came out of pretty much nowhere, poorly communicated, and rather vague in actually backing them up. Which... at least from the "backing up the complaints", has been the theme for the screaming folk thus far. If people are missing the point, there are two possibilities- either A) everyone else is a moron and too stupid to understand your points, or more likely B) you're communicating poorly. Assuming that the other party is the idiot (a) when more likely then not it's you (B) isn't really a good way to try and get your say. > > > 2) issues with eclass changes which will result in bug spam > > > > You're not supposed to change the exposed api of eclasses in the tree > > (something y'all do violate I might add, which is a seperate QA > > matter). Same issue applies to the 'official' overlays offered by > > devs also, and to the tree in general. > > We can change eclasses all the time, assuming all relevant ebuilds in the > tree > get adjusted - just that no one cares for any overlay. No, actually you cannot. Just because you update the tree doesn't mean you're not going and breaking binpkgs, or the vdb installation. Read glep33 if you want the sordid back history and solution to it. Like I said, y'all violate it, doesn't mean it's right. > > It's a reaching statement, bluntly. Using such an arguement has the > > side affect of stating that no overlays should ever exist, because > > they suffer the same potentials. > > Local overlays are fine as the user exactly knows what he does in his private > overlay (and hopefully follows eclass changes), development overlays are fine > (assuming the group of people controls the releavant overlays as well), > overlays like Sunrise are problematic, not to use such anal words as you do. Why are they problematic? Because of your assumption that they won't maintain it? It's the same thing as gentoo-x86 (I will keep stating that till it's grilled into peoples heads also), this is _not_ a new issue so why are people leveling issues of gentoo-x86 as new issues of sunrise? So someone goes and breaks something in gentoo-x86 that breaks something for sunrise. Fine, it's sunrises' mess to clean up; they've volunteered to do this work, I don't see how you can claim it as a negative when they've accepted it as part of _their_ work. > > > 3) the fact that sunrise is a bunch of arbitrary packages, instead close > > > related ones managed by one team, that does exactly maintain relevant > > > packages. > > > > What the hell do you think the tree is? It's a bunch of arbitrary > > packages maintained loosely by subgroups of people; you're stating > > that sunrise is too loose yet gentoo-x86 is fundamentally no > > different. > > > > Sunrise is pretty much the same damn thing. > > Exactly that isn't right. No one cares for compatibility of the main tree > (eclasses, conflicts between ebuilds with regards to installed files) and > Sunrise ebuilds. Worth noting sunrise folk may be gentoo devs also- and as stated above, they're trying to extend beyond gentoo-x86; it's not like they're demanding you do things their way- far from it, it's actually the reverse, devs demanding things of sunrise. You break their shit, they'll fix it (it's the nature of this relationship, even though it should be _cooperative_ instead of "get lost" that seems to be the norm now). So again... how is this a negative? It's *their* damn time- if you wanted to be an ass and go break their stuff, as retarded as it is you _could_ because they stepped up for the job. Granted, they may give you the finger and quit, or your remaining fellow devs may rightfully boot you for playing games, but the point stands- they stepped up to do the work, including cleaning up anything y'all may break for them. You're not limited- they're the ones limited via trying to not step on gentoo-x86's toes. How is that a negative then? ~harring
pgprgaaVxECIC.pgp
Description: PGP signature
