My sense of this is that there is a desire to reduce the "threat surface" of the SVN by requiring committers to opt-in. (I assume there is some way to decide which committers to grandfather.) Apparently, that is a one-time act and it doesn't alter being relatively inactive. So I guess this will have to be a periodic ceremonial requirement.
I take it that this means an attacker breaks into an existing committer's account in some manner, impersonating that committer in a manner that (1) the committer doesn't notice (possible) and that (2) it doesn't attract attention on the commit logs (i.e., CTR fails at R). It seems to me that new activity by an inactive committer (that orcmid fellow, for example) would be noticed and it would be difficult to do anything that looked suspicious. (Orcmid did make a commit recently, but it was to fix something on the web site and it was done via the CMS.) I also don't understand how phishing would work. I can't imagine receiving anything that requires me to use my @apache credentials anywhere without attracting great concern. If there's a successful Man-in-the-Middle exploit against the SVN, it is not the inactive committers that are going to be hacked. As far as I know, the only successful attacks against the ASF (and Apache committers) involved compromising servers and stealing password hashes, making them vulnerable to off-line password discovery. The mitigation seems to have worked. I think an use it or lose it approach to committer authorization might be more effective. It won't get the account off the books (as far as I know), but it would shrink the authz surface of the individual project code base. Fortunately, that will not disturb the bugzilla or authorization to edit on Planet Apache, afaik. - Dennis -----Original Message----- From: Rob Weir [mailto:robw...@apache.org] Sent: Wednesday, April 03, 2013 13:17 To: dev@openoffice.apache.org; <orc...@apache.org> Subject: Re: Proposal: Improve security by limiting committer access in SVN [ ... ] It is not about trusting the committers. It is about reducing the exposures to hackers. Trust of the committer has nothing to do with it. Every active authorization in SVN is a vulnerable opening for a hacker, who can gain access, via any number of phishing methods in common use today. It us only prudent that a committer not have that authorization unless they are using it. -Rob [ ... ] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
