[
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15945523#comment-15945523
]
Hoss Man commented on SOLR-10338:
---------------------------------
{quote}
If we are using a non-blocking source for the random number generator, I don't
think we need to check entropy or warn about it. It seems that people who
really understand what's going on say that the non-blocking source is preferred
over the blocking source for all production usage, and only hardcore crypto
researchers are likely to need the blocking source.
In my own development efforts outside of Solr, I have seen that when a Tomcat
server starts up, configuring "/dev/./urandom" for the java random source can
reduce the startup by ten to fifteen seconds.
{quote}
shawn: i feel like you are convoluting 3 distinct questions/ideas...
# overriding SecureRandom _*in tests*_ ... which is what this current issue is
about. In a test situation, there is no downside (that i can think of) in
forcing a particular source of "randomness" -- and in most cases forcing a
"consistent" use of randomness is a good idea to improve reproducibility. In
general in our unit tests, we're also already specifically not concerned with
having truly "secure" randomness (see SSL parent issue SOLR-5776)
# overriding SecureRandom _*in production code*_ ... this is a much sensitive
situation. we should be very careful about arbitrarily deciding that
{{bin/solr}} should override the source of secure randomness since that could
cause security holes in SSL and security features that rely on encryption.
# warning the user about low entropy ... regardless of _what_ entropy source is
being used, which is what the (original) point of SOLR-10352 was.
We should keep these issues/discussions isolated and discrete. Choices we make
regarding our test scaffolding (which may be fundamentally insecure, but
helpful for speed) are not necessarily the same choices we want to make in our
end user production scripts.
> 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, 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]
