[
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: [email protected]
For additional commands, e-mail: [email protected]
