If the problem is that there are abandoned Apache credentials out there for the taking, the solution is to deal with the inactive committers and revocation of those credentials. And to assume that some sudden resuscitation can go unnoticed strikes me as not very plausible. (It strikes me as far more likely that such committers have lost/forgotten/mislaid their credentials and having them fall into the wrong hands is probably not a material risk.) The claim that there is automatic inclusion of malicious code introduced by a previously silent committer seems unsupportable.
Whatever is done has to work without injury to "the Apache Way." Furthermore, modifications to code on the SVN are always reversible. That is considered the main line of defense for inappropriate commits to the SVN. (Use of the web site to create an exploit against browsers is a different problem that might need to be looked into. That's more immediate than attempting to get a patch by a watchful release manager. And, as far as I know, all web site updates also show up on the commit logs.) We've been taken through this rationale before. Why is it being raised anew? Has there been an actual exploit? I am having trouble accepting that there is a plausible risk of undetected exploit here, versus the kinds of attacks that could have far more serious consequences. There are exploits that are already far easier without anything happening at the ASF end of things. Having reliable code signatures would give us a way to discourage and repudiate the continuing reliance on exploit-vulnerable downloads that folks are now being exposed to. There are places in AOO worthy of investigation to limit the ways an AOO install might be an exploit enabler that are probably more important than the proposed defense of the SVN by requiring committer opt-in. I assume the opt-in should be requested using the apache @a.o e-mail (will that be part of the rules)? Will there be some e-mail confirmation requirement to protect against the account *already* having been compromised? Otherwise, this is all self-prescribed placebo. I shall not say anything further about whether or not this is done. While it may set some minds at ease, I think it is not doing much in terms of where the plausible threats already are and where opportunistic exploits may already be happening. - Dennis PS: It seems to me that the special authz arrangements and SVN areas for security fixes has to do with avoiding premature disclosure of a known vulnerability that is already in released code. The list is private and moderated for obvious reasons. Likewise, the private @oo.a.o is for preserving the confidentiality of certain conversations (and that authz is for related material on the SVN). There is no confidentiality to protect in the public code base. That's the point. -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Thursday, April 04, 2013 09:44 To: dev@openoffice.apache.org Subject: Re: Proposal: Improve security by limiting committer access in SVN On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti <pesce...@apache.org>wrote: > 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. > > Would Infra need to maintain the authz , or would that be something that you do? Note: we already have a separate authz for openoffice-security and openoffice-pmc, for the same reasons -- there are some things that should not be authorized for all committers. Going from 3 authz's to 4 is not unreasonable, IMHO. > 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. > > None of these get automatically included in releases that are installed on tens of millions of machines. So I would not ask for additional controls here. I'm asking only for additional controls on source code. > 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. > > I'm not concerned with things where social enforcement would work. It is not a concern that someone unqualified makes a change to the source code merely because they have permissions. The issue is that the product is so well-known and so broadly installed that it is automatically a target for hackers, and with so many authorized user accounts from committers who are not actively coding, or never were, that these authoriziations are particularly vulnerable to compromise. I believe this a serious issue and we act irresponsibly and do a disservice to our users if we treat this merely as an inconvenience or a social faux pas. -Rob > Regards, > Andrea. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<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