[
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021555#comment-16021555
]
Hoss Man commented on SOLR-10338:
---------------------------------
no major concerns.
minor concerns...
* the {{log.info}} about java.security.egd being null should probably be a
warning
** shouldn't there *also* be a warning if java.security.egd is non-null but not
equals to {{"file:/dev/./urandom"}} ?
* shouldn't the very first thing in the assertion failure message be a
suggestion to try setting {{-Djava.security.egd=file:/dev/./urandom}} and only
if that doesn't work use the {{test.solr....}} property to disable these checks?
* I'd feel more comfortable with something like the {{final String allowed =
System.getProperty("test.solr.allowed.securerandom");}} and associated
validation/logging in the snipped i suggested above (instead of a simple
{{Boolean.parseBoolean(System.getProperty("test.solr.allow.any.securerandom","false")}})
** same amount of work from an end user to bypass the checks (add 1 sys prop
they cut and past from failure msg)
** would help ensure that if/when they do bypass with that system property,
they'll get an error to revisit that decision if/when something happens to
change the SecureRandom in the future (ie: perhaps later upgrade their JVM, or
change how they run the tests such that our attempts at setting
"java.security.egd" start working)
** ie: i'd rather they get a nice error that they said they expect to be
running algortihm=foo, but it's not so maybe they should remove the
"test.solr.allowed.securerandom" and try setting "java.security.egd" again then
just silently be using a blocking SecureRandom forever.
* even if nothing else changes, the quick {{return}} if the user has disabled
these checks (with whatever {{test.solr....}} sysprop we use) should probably
log something about bypassing the non-blocking SecureRandom checks.
> 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]
