[
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15939025#comment-15939025
]
Mihaly Toth commented on SOLR-10338:
------------------------------------
bq. Is there a similar change we can make to help people running tests from
maven? (and the IDEs that we have project starter files for in dev-tools?)
Good point, thank you. Those files just avoided my attention. Yes, I guess we
should update them too. In maven we can add a system property to the surefire
and the failsafe plugin in the _lucene-solr-grandparent_ pom template, like:
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
...
<systemPropertyVariables>
<java.security.egd>file:/dev/./urandom</java.security.egd>
...
</systemPropertyVariables>
</configuration>
</plugin>
{code}
As far as the IDEs concerned, we could also do that. Probably this is not that
much of a pain as the ant setting, because on your desktop you usually have
just enough entropy and you run only parts of the test suite at once. Anyway, I
will have a look at it tomorrow how to update Eclipse and Idea templates.
bq. For testing purposes asserting that "SHA1PRNG" is always used by the JVM
(for example: in a SolrTestCaseJ4 @BeforeClass method) seems like an idea worth
considering ... if for no other reason then it should help improve randomized
seed reproducibility across diff JVMs ... we could always have support for
something like a test.solr.allow.any.securerandom=true sys prop that users
could set to override this assert.
That @BeforeClass approach is much stricter. This would mean that if the flag
is not set, all Solr tests fail, and the output of the test run will become
useless. Maybe a single test is just enough as an indicator test. Or are you
thinking of failing the tests fast and to prevent false negative tests?
bq. How about adding a warning in the startup script for Linux
This sounds like a good idea to me too. Let me give some comments on this in
SOLR-10352.
> Configure SecureRandom non blocking
> -----------------------------------
>
> 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: 4.9, 6.0
>
> Attachments: 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
