You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Brian Chess <br...@fortifysoftware.com> on 2006/12/19 06:16:06 UTC
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 <va...@tcs.com>: budding code auditor at TCS
Martin Englund <ma...@sun.com>: Experienced auditor at Sun
gfua@caramail.com: Looks like he's just testing the waters
Lucene, Nutch, Solr
------
Thierry De Leeuw <th...@avanco.be>: experienced vulnerability hunter
Michael Bunzel <mr...@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
Re: access policy for Java Open Review Project
Posted by Doug Cutting <cu...@apache.org>.
Brian Chess wrote:
> My question is, would you like to allow outsiders to go through results and
> help sort the real bugs from the chaff?
That's up to you. It's your service, not governed by the Apache Lucene
project. If you cause your system to add reasonable issues to our
bug-tracking system, then we will take over from there. If you wish to
provide a free service that we administer, then the project should vote
to decide whether it wants to take on that duty.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: access policy for Java Open Review Project
Posted by Chris Hostetter <ho...@fucit.org>.
: application vulnerable or is really just a "ruckus" issue? Part of
: me thinks that b/c the code is freely available, people could find
: the security issues anyway, so we aren't really protecting ourselves
: anyway by denying access.
Personally I agree ... if the source is free, all exposing vulnerabilities
to the public can do is give more people the power to submit patches.
Anyone truely nefarious can run FindBugs (or purchase copies of the
Fortify commercial analysis applications) on the source code directly and
get the same information.
Then again: my involvement with "high profile" open source projects is
relatively short lived ... there may very well be a lot of 'old timers'
with horror stories of past experiences that demonstrate why some aspects
of Open Source projects need to be less open then others to protect the
user base.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: access policy for Java Open Review Project
Posted by Grant Ingersoll <gs...@apache.org>.
On Dec 19, 2006, at 12:16 AM, Brian Chess wrote:
>
> 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.
Are there any security concerns (I think your original intro said you
don't generally share w/ the public) of having others involved? That
is, could we be publishing information that could make a Lucene
application vulnerable or is really just a "ruckus" issue? Part of
me thinks that b/c the code is freely available, people could find
the security issues anyway, so we aren't really protecting ourselves
anyway by denying access.
Thanks, btw, for the account and for setting this up.
--------------------------
Grant Ingersoll
Center for Natural Language Processing
http://www.cnlp.org
Read the Lucene Java FAQ at http://wiki.apache.org/jakarta-lucene/
LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: access policy for Java Open Review Project
Posted by Daniel Naber <lu...@danielnaber.de>.
On Wednesday 27 December 2006 01:38, Erik Hatcher wrote:
> I'd be surprised if anyone uses Lucli, given the limited utility it
> has versus using Luke.
It's actually very useful if you only have ssh access to a machine that has
no X11 running. I just fixed the small bug found by this review.
Regards
Daniel
--
http://www.danielnaber.de
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: access policy for Java Open Review Project
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Brian,
Thanks for your continued efforts, and for this report about Lucli.
I'd be surprised if anyone uses Lucli, given the limited utility it
has versus using Luke.
Erik
On Dec 26, 2006, at 4:30 PM, Brian Chess wrote:
> 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 <br...@fortifysoftware.com>
>> Date: Mon, 18 Dec 2006 21:16:06 -0800
>> To: <ja...@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 <va...@tcs.com>: budding code auditor at TCS
>> Martin Englund <ma...@sun.com>: Experienced auditor at Sun
>> gfua@caramail.com: Looks like he's just testing the waters
>>
>> Lucene, Nutch, Solr
>> ------
>> Thierry De Leeuw <th...@avanco.be>: experienced vulnerability
>> hunter
>> Michael Bunzel <mr...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: access policy for Java Open Review Project
Posted by Brian Chess <br...@fortifysoftware.com>.
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 <br...@fortifysoftware.com>
> Date: Mon, 18 Dec 2006 21:16:06 -0800
> To: <ja...@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 <va...@tcs.com>: budding code auditor at TCS
> Martin Englund <ma...@sun.com>: Experienced auditor at Sun
> gfua@caramail.com: Looks like he's just testing the waters
>
> Lucene, Nutch, Solr
> ------
> Thierry De Leeuw <th...@avanco.be>: experienced vulnerability hunter
> Michael Bunzel <mr...@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