openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Proposal: Improve security by limiting committer access in SVN
Date Thu, 04 Apr 2013 18:59:10 GMT
Sarcasm accepted. Thank you.

On Thu, Apr 04, 2013 at 02:54:41PM -0400, Rob Weir wrote:
> Sorry for talk posting.  I get it now.  If AOO is more secure than other
> Apache projects than this may give the impression that the other projects
> are less secure because they do not take these precautions.  No project can
> be better than others since that implies some are worse.  So any attempt to
> improve must be resisted since it reflects poorly on the projects that
> don't.
> 
> I apologize for not noticing this before.  I understand completely.  It is
> a very human reaction.   I guess I'll just wait for the time to come for
> other projects to figure this out, through whatever painful lessons await
> them, so we can then move forward together, at the same pace.
> 
> -Rob
> 
> 
> On Thu, Apr 4, 2013 at 2:33 PM, Rob Weir <robweir@apache.org> wrote:
> 
> >
> >
> >
> > On Thu, Apr 4, 2013 at 2:10 PM, Greg Stein <gstein@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:pescetti@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-unsubscribe@openoffice.apache.org
> >> > > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> > >
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> > > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message