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 > >
