Re: access policy for Java Open Review Project
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: budding code auditor at TCS Martin Englund [EMAIL PROTECTED]: Experienced auditor at Sun [EMAIL PROTECTED]: Looks like he's just testing the waters Lucene, Nutch, Solr -- Thierry De Leeuw [EMAIL PROTECTED]: experienced vulnerability hunter Michael Bunzel [EMAIL PROTECTED]: experienced auditor, but new to auditing Java Thoughts? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]: budding code auditor at TCS Martin Englund [EMAIL PROTECTED]: Experienced auditor at Sun [EMAIL PROTECTED]: Looks like he's just testing the waters Lucene, Nutch, Solr -- Thierry De Leeuw [EMAIL PROTECTED]: experienced vulnerability hunter Michael Bunzel [EMAIL PROTECTED]: experienced auditor, but new to auditing Java Thoughts? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene code review
Hi Erik, thanks for the intro. I'd be happy to set up an account for anyone involved with the projects who'd like to take a look. (Because we're checking for security problems, we don't share specific findings with the general public.) Erik is right, from Lucene, Nutch, and Solr, the most important things we found were the cross-site scripting bugs in Solr. There are a few more bugs that I think are worth looking at, but nothing to get worked up about. Brian From: Erik Hatcher [EMAIL PROTECTED] Date: Thu, 14 Dec 2006 23:43:33 -0500 To: java-dev@lucene.apache.org Cc: Brian Chess [EMAIL PROTECTED], Gary McGraw [EMAIL PROTECTED] Subject: Re: Lucene code review On Dec 13, 2006, at 1:00 AM, Otis Gospodnetic wrote: Just spotted this on Slashdot: http:// opensource.fortifysoftware.com/welcome.html I wonder what the 3 defects they found and reviewed are... I don't see a way to see them from their site. I had an early peek at the Fortify analysis of several open source projects, primarily Lucene, Nutch, and Solr. Lucene and Nutch both had very minor cosmetic issues (don't recall off the top of my head what they were). Solr had cross-site scripting issues in its JSP pages, which I think are now all fixed (?). Brian Chess at Fortify was instrumental in the analysis and is eager to work with open source communities closely to have these types of analyses automated and useful to the projects. I'm sure we'll hear more from his organization in the near future. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
