Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: domain of brian@fortifysoftware.com
 designates 209.172.101.151 as permitted sender)
User-Agent: Microsoft-Entourage/11.2.5.060620
Date: Tue, 26 Dec 2006 13:30:58 -0800
Subject: Re: access policy for Java Open Review Project
From: Brian Chess <brian@fortifysoftware.com>
To: <java-dev@lucene.apache.org>
Message-ID: <C1B6D492.22DAD%brian@fortifysoftware.com>
Thread-Topic: access policy for Java Open Review Project
Thread-Index: AccjLMjvB57u8o8gEdubqAARJM8j1gGCFjWh
In-Reply-To: <C1ACB596.226B8%brian@fortifysoftware.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi there, I didn't see any replies to my question about what to do with
outside auditors for the Java Open Revew Project. Our default position is
that we do not allow access to outsiders without permission from the code
maintainers, so unless I hear otherwise, we won't grant access to outsiders
for Lucene projects.  That's a fine policy as far as I'm concerned.  I just
wanted to let people know where we stand.

Meanwhile, we're moving closer to performing regular analysis of the code.
On Friday we uploaded our second pass at Lucene.  I only took a quick glance
through the results, but this one caught my eye:

Lucli.java line 286:
    name.toLowerCase(); //treat uppercase and lower case commands the same

I'm pretty sure that line should be:
    name = name.toLowerCase();

I'll send another note when we've switched over to a regular recurring
analysis.

Happy holidays,
Brian


> From: Brian Chess <brian@fortifysoftware.com>
> Date: Mon, 18 Dec 2006 21:16:06 -0800
> To: <java-dev@lucene.apache.org>
> Conversation: access policy for Java Open Review Project
> Subject: access policy for Java Open Review Project
> 
> Hi all, I've been busy creating JOR accounts this weekend, and it was cool to
> see so many names from Lucene.  Lucene, Solr, and Nutch have the lowest defect
> rates among the projects we've looked at, and I'm beginning to see why.
> 
> One of the things JOR is doing is inviting people to come and help review
> issues we find with static analysis.  We've had a fair number of signups
> since the project was on slashdot.
> 
> My question is, would you like to allow outsiders to go through results and
> help sort the real bugs from the chaff?  The upside is that volunteers may
> perform useful work and that it may be another avenue to get people involved
> with the code.  The down side is that things like XSS in admin pages may lead
> them to make more ruckus than is really appropriate.
> 
> The situation may change if we can establish a mechanism for efficiently
> moving issues into Jira, but for now, I could imagine a number of different
> policies, including:
>   - Allow anyone access who asks for it.
>   - Allow access on a case-by-case basis.
>   - Don't allow access to outsiders.
> 
> Here are the "outsiders" who've requested access so far, along with a few
> words to summarize what they've told me about themselves.
> 
> Lucene
> ------
> Varun Nair <varun.nair@tcs.com>: budding code auditor at TCS
> Martin Englund <martin.englund@sun.com>: Experienced auditor at Sun
> gfua@caramail.com: Looks like he's just testing the waters
> 
> Lucene, Nutch, Solr
> ------
> Thierry De Leeuw <thierry@avanco.be>: experienced vulnerability hunter
> Michael Bunzel <mrb@lintranex.com>: experienced auditor, but new to
>                                     auditing Java
> 
> Thoughts?
> Brian


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