[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448527#comment-13448527
]
Uwe Schindler edited comment on LUCENE-4332 at 9/5/12 5:58 PM:
---------------------------------------------------------------
{code}
permission java.security.SecurityPermission "*", "read,write";
{code}
This makes no sense, as SecurityPermission has no "action", so "read,write"
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite....
bq. rather than as a full force prevention of malicious code
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a "new feature" to Solr that needs additional permissions.
I am already working on restricting "RuntimePermission" more, so only things
like "reflection" and "property access" is allowed.
was (Author: thetaphi):
{code}
permission java.security.SecurityPermission "*", "read,write";
{code}
This makes no sense, as SecurityPermission has no "action", so "read,write"
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite....
bq. rather than as a full force prevention of malicious code
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a "new feature" to Solr that needs additional permissions.
I already working on restricting "RuntimePermission" at all, so only things
like "reflection" and "property access" is allowed.
> Integrate PiTest mutation coverage tool into build
> --------------------------------------------------
>
> Key: LUCENE-4332
> URL: https://issues.apache.org/jira/browse/LUCENE-4332
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.1, 5.0
> Reporter: Greg Bowyer
> Assignee: Greg Bowyer
> Labels: build
> Attachments:
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
>
>
> As discussed briefly on the mailing list, this patch is an attempt to
> integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
