Ah NO. Those so-called "phantom" committers
had their commit to this projext revoked when you graduated
to a TLP, but the larger point that Greg's making
remains true- it is a false sense of security to
rely on ACL's to pretend you don't need to vet your
commit list. See http://www.apache.org/dev/open-access-svn
for more details of an ongoing debate to simplify
our svn rules accordingly.
>________________________________
> From: Rob Weir <robw...@apache.org>
>To: "dev@openoffice.apache.org" <dev@openoffice.apache.org>
>Sent: Thursday, April 4, 2013 3:53 PM
>Subject: Re: Proposal: Improve security by limiting committer access in SVN
>
>On Thu, Apr 4, 2013 at 3:17 PM, janI <j...@apache.org> wrote:
>
>> On 4 April 2013 21:03, Rob Weir <robw...@apache.org> wrote:
>>
>> > 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?
>> >
>>
>> Just a stupid question from someone who have not been here for ages...the
>> person just described should loose the committer role, or are we granted
>> commitership for lifetime ??
>>
>>
>"Typical" and "Apache OpenOffice" should never be used in the same sentence
>unless mischief is intended ;-)
>
>But other projects, being a committer is permanent, aside from resignation
>or extreme cases. But for most projects becoming a committer requires
>being involved with the project, demonstrating merit, being voted in by a
>PMC, etc., just like you did.
>
>But with OpenOffice, there was a two week period of time when we rapidly
>bootstrapped the community by making people committers automatically, on
>day 1. All they had to do is put their name on a wiki page and return an
>ICLA and they were committers. No vetting, no vote. Quite a few of them
>never got involved in the project in even the least degree. So we have
>these phantom community members, with authorization to change the source
>code.
>
>Regards,
>
>-Rob
>
>
>
>> jan I.
>>
>> >
>> > -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
>> > >
>> > >
>> >
>>
>
>
>
