On Thursday 03 August 2006 04:56, Brian Harring wrote: > *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).
The difference is that I argue, while you accuse me to play false. I consider this as ad hominem and together with all this "FUD" and "BS" calling, in contrary to my email, inflammatory. > > 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. This wasn't meant condescending, but a true request. Because it's not the first time you react this way, when you dislike another ones opinion. It is as annoying as Ciaran's habit to make statements without backing them up - even when asked to do so. > 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. I wrote that you should read my replies in the initial thread. > If you wanted to home in vulns in the source (which isn't security as > much as 'vulnerabilities in the source'), be explicit. I was. > 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? The difference is that people are using them in their local overlay and therefore - in contrary to the Sunrise overlay - a) are only exposed to the packges they _really_ want to use and b) are responsible for it themselves. Aside of this I might add that I do add comments to bug reports, when I stumble about vulnerability notices and find relevant bug reports. > 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). Dumping ground or not. It's easy to miss vulnerability notices. Especially, if you don't have guys who expclicitly care for it. And you need a security team to announce issue to the user base. I wouldn't use Gentoo, if we not had such a hard and good working security team. > 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). Interesting to see you state this. Because this is a far more serious problem, than supporting "everything" possible; And Sunrise won't fix this either - if not the opposite. One of the goals of Sunrise is to recruit new devs. But we don't need new devs to add new packages primarily, we more to maintain existing and not so fancy stuff and to clean out the tree. > 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). Your list is rubbish. There're stable versions for all security wise supported architectures and the relevant GLSA's. If users don't use them, it's their local problem. > > > 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. Do I have to learn you to read? See above. > > 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. Is that a joke or what? I do support GLEP 33, but it's not implemented yet. Also I can change eclasses in many ways breaking third party ebuilds, but not binary packages. That aside, relying on binary packages without taking a snapshot of the tree is rather brave. Gentoo is a more or less dynamic source distribution and there is no ensurance binary packages will work "forever". > > 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? As I said: Security issue, eclass incompatiblities. Want another example? Here it is: What if you have packges that need to block each other (usually because of installing the same files). Mutual cross overlay blockers? Forget it. > 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. The problems will pile up in bugs.g.o and "usally" with the wrong addressee. This has been every now and then the case with other overlays as well as users of distros building on Gentoo. I can live with that to a degree. But when we do this mess ourselves, it get's highly annoying. > 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. I have answered all that above. > 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 doing it again. No I'm not playig games with you. I have reasonable complaints and consider this sort of overlay a failure. Then an extra development tree would be much better. > 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? I fear for the security of our user base, especially the lazy, uneducated ricers and how this wll reflect on Gentoo's reputation as a whole. I fear more annoying, invalid bug reports. I don't see any benefit for the existing tree or Gentoo as a whole. Carsten
pgpjEGkQIeqLN.pgp
Description: PGP signature
