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.
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 <[email protected]> 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:[email protected]]
> > > > Sent: Thursday, April 04, 2013 08:57
> > > > To: [email protected]
> > > > 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: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
