You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mihaly Toth (JIRA)" <ji...@apache.org> on 2017/05/03 17:41:04 UTC
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking
for tests.
[ https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mihaly Toth updated SOLR-10338:
-------------------------------
Attachment: SOLR-10338.patch
I tried again setting {{java.security.egd}} from a class itself. It is possible to set it, and it does have an effect on the algorithm selected given that the Sun security provider is loaded after that. Please see my opening comment on this Jira for code snippets.
So I believe it is possible. The other question is if it is needed. The only motivation now are other projects that are depending on {{SolrTestCaseJ4}}. With setting the property if it is unset, there is a chance that those projects are not broken.
In Solr test however I would not rely solely on this solution because this is not bullet proof. If any other test not subclassing {{SolrTestCaseJ4}} AND using directly or indirectly {{SecureRandom}} would run before {{SolrTestCaseJ4}} subclassed tests then all these later tests would fail. This is because the algorithm is decided on first usage of {{SecureRandom}}. I did a test run having only setting the property in setup and I have got couple of failures.
The attached patch uses {{test.solr.allow.any.securerandom}} system property to allow validation of the algorithm defaulting to true. In case of algorithm verification I blacklisted {{NativePRNG}} and {{NativePRNGBlocking}}. According to https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SUNProvider those are the algorithms using {{/dev/random}} in one way or another.
Regarding the question on how stable it is to overwrite this property from code I found no mentioning of any limitation where the property could be set. Among other page I read the javadoc of https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/classes/sun/security/provider/NativePRNG.java . So I do not think this behaviour would change in any future versions of Java 8. NativePRNG in Java 9 is only a skeleton implementation. And we have the test suite as a last resort to tell if such unexpected event occured.
> Configure SecureRandom non blocking for tests.
> ----------------------------------------------
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
> Issue Type: Sub-task
> Reporter: Mihaly Toth
> Assignee: Mark Miller
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we could get rid of random entropy exhaustion issue related to all usages of SecureRandom.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org