Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)

[Brian Harring]

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