On Thu, Apr 4, 2013 at 2:57 PM, Greg Stein <gst...@gmail.com> wrote:
> Your proposal to alter the community structure is premised upon a
> strawman risk. First, that it would occur. Second, that it wouldn't be
> noticed. Third, that it would find its way into users' hands.
>
>
So you are asserting that someone who put their name down on the Incubator
wiki in July 2011 and was named a committer by that act, but never ever
showed up after that, never joined the dev list, never posted to the dev
list, never contributed code or anything else other than a name on a wiki,
is a member of our community and it would be altering the committee
structure if we removed their authz to our source code, even with the
proviso that we would immediately restore it on request?
Really?
-Rob
> In the past, the Foundation has *explicitly* said that we would accept
> a certain level of risk to maintain our communities.
>
> I find your strawman at a level even *lower* than the scenario that
> I'm thinking about(*).
>
> If you're worried about stale committers suddenly inserting trojans,
> then just use 'svn log' to find those outliers. No need to create
> division within the community. Run a simple histogram. There are many
> solutions to your purported attack vector, than to divide into groups.
>
> Cheers,
> -g
>
> (*) a certain large company's lawyer (ahem) was trying to scare the
> ASF ("the risk!!") into adopting certain procedures; we shut her down
>
> On Thu, Apr 04, 2013 at 02:33:12PM -0400, Rob Weir wrote:
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein <gst...@gmail.com> wrote:
> >
> > > Also, let me say one more thing:
> > >
> > > This notion of creating divisions among committers ... it is "solving"
> > > a problem that has never occurred here.
> > >
> > > NEVER. OCCURRED.
> > >
> > >
> > So frickin' what? That is entirely irrelevant. My house has never
> burnt
> > down either, but I still don't leave open flames around unattended. In
> > fact you might think this is naive view, but avoidance of such risks
> might
> > even be correlated with lack of house fires. Hmmm....
> >
> >
> >
> > > In the Foundations's 14+ year history, we have never seen a trojan
> > > commit. Our servers have been compromised a handful of times. When we
> > > were back on CVS, we even had to audit source control to verify no
> > > trojan injection. But we have NEVER had a case of a malware commit.
> > >
> > >
> > Again, that proves nothing. I'm sure the first time apache.org was
> rooted
> > that it had never happened before either, right?
> >
> >
> >
> >
> > > So back to IMO: dividing and partitioning and separate privilege
> > > levels... there is no reason. It creates a social problem to "solve" a
> > > non-existent issue. Net result: more problems.
> > >
> > >
> >
> > Greg, we already do this. Does every ASF Member have credential for
> Infra
> > root? Does ever ASF Member have access to legal-private mailing list.
> No.
> > No. We even do this in the AOO project, with separate authz for
> > openoffice-security, which by the way also includes an SVN tree.
> >
> > Anyone who thinks this is a question of dividing and privilege is
> > expressing a knee-jerk reaction, without thinking of the risks. We
> should
> > avoid regurgitating platitudes. Remember, we're talking about people who
> > have never committed code, who don't even know C, who are not even
> > subscribed to the dev mailing list, and in some cases have never ever
> > posted to our mailing lists. They signed up in with the podling in July
> > 2011 and then were never heard of again. You make an extremely weak
> > argument to pontificate about "privilege" here.
> >
> > The risks are real. High profile open source projects attract these
> kinds
> > of attacks. There are those who know it, and those who don't know it
> yet.
> >
> > A good read:
> >
> http://www.securityweek.com/linux-source-code-repository-kernelorg-gets-hacked
> >
> > As for those who think that casual review of commit messages will review
> > any attack, that is a dangerously naive few. We should not expect an
> > attack to be in a filed called trojan.c with comments and clear logic
> > explaining what the code does. Any hacker with a clue would send a patch
> > backed by a reasonable defect report in Bugzilla that would be innocuous
> to
> > casual inspection. All you need is a buffer or stack overwrite in a
> > well-placed area to cause the problem. This might even be done in two
> > stages, spread out over time, so the impact is not detectable without
> > looking at the pieces together.
> >
> > Now if someone did that in the name of an active committer it would be
> > *immediately* detected. "WTF!? I didn't check that in!" But when done
> in
> > the name of an unactive committer it would be less likely to be noticed
> for
> > what it is. We might check twice, but that doesn't mean we'd catch all
> or
> > even most deliberate attacks. But whatever detection rate we would have
> > there it would be far less than the presentation rate for not having
> > authorization enabled at all. The prevention rate there is 100%
> >
> > Regards,
> >
> > -Rob
> >
> >
> >
> >
> >
> > > Cheers,
> > > -g
> > >
> > > On Thu, Apr 04, 2013 at 05:59:31PM +0000, Greg Stein wrote:
> > > > Speaking as one of those "old-hands", Dennis is absolutely spot-on.
> > > >
> > > > Partitions, barriers, sub-groups... I call those "divisive"
> mechanisms
> > > > which serve to divide the community. Such divisions are rarely
> needed.
> > > >
> > > > As Andrea points out, in Subversion's 13 year history, we have only
> > > > *requested* people observe certain fences. We have never had a
> > > > problem. We have never had to take sanctions. A stray commit here and
> > > > there? Sure, it has happened, with the best intent, so we just point
> > > > out that they need a bit more caution. No harm done.
> > > >
> > > > Back to Dennis' point: the solution here is proper review of the
> > > > commits that occur. (IMO) NOT a way to *exclude* or to *limit* the
> > > > potential contributions of others.
> > > >
> > > > Cheers,
> > > > -g
> > > >
> > > > On Thu, Apr 04, 2013 at 09:23:39AM -0700, Dennis E. Hamilton wrote:
> > > > > In previous generations of this kind of discussion, the ASF
> old-hands
> > > will point out that the social process works quite well, folks don't do
> > > commits unless they feel qualified to do so, and it is often the case
> that
> > > committers will request RTC (i.e., submit patches rather than update
> the
> > > SVN) in contributing where they are not experienced or don't consider
> > > themselves expert.
> > > > >
> > > > > At the ASF this appears to be one of those, "if it is not broken,
> > > don't fix it."
> > > > >
> > > > > There is still the concern about stolen credentials used to perform
> > > undetected malicious acts. If the oversight that the project naturally
> > > brings to bear on visible changes to the code base is insufficient, I
> think
> > > the problem is greater than there being a possible exploit of that
> > > inattention. Mechanical solutions may be part of the disease, not the
> cure
> > > [;<).
> > > > >
> > > > > - Dennis
> > > > >
> > > > > -----Original Message-----
> > > > > From: Andrea Pescetti [mailto:pesce...@apache.org]
> > > > > Sent: Thursday, April 04, 2013 08:57
> > > > > To: dev@openoffice.apache.org
> > > > > Subject: Re: Proposal: Improve security by limiting committer
> access
> > > in SVN
> > > > >
> > > > > Dave Fisher wrote:
> > > > > > Let's focus only on adding one new authz list for the code tree.
> > > > > > Call it openoffice-coders and populate it with those who HAVE any
> > > > > > commit activity in the current code tree.
> > > > >
> > > > > I checked feasibility with Infra. Summary:
> > > > >
> > > > > 1) LDAP is not the solution. Rule it out.
> > > > >
> > > > > 2) The only possible solution would be an authz rule like
> suggested by
> > > > > Dave here; however, Infra quite discourages it, mainly for
> maintenance
> > > > > reasons. This leads me to think we would need some good
> justifications
> > > > > for implementing this.
> > > > >
> > > > > 3) If the justification is security, then there are other
> privileges to
> > > > > monitor. Namely, every committer has shell access to
> people.apache.org
> > > ,
> > > > > authenticated access to the Apache SMTP server and CMS privileges
> for
> > > > > the openoffice.org website, including publish operations.
> > > > >
> > > > > For the record, the Subversion project has complex rules like Rob
> > > > > pointed out; but it's only a "social enforcement", i.e., all
> committers
> > > > > respect those limitations by their own choice; if you look at the
> > > > > technical level, every committer (all Apache committers) can commit
> > > code
> > > > > to the Subversion subtree.
> > > > >
> > > > > Regards,
> > > > > Andrea.
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
