From: Uwe Schindler <u...@thetaphi.de>
Sent: Monday, February 12, 2018 2:31 AM
Subject: RE: SecureRandomAlgorithmTesterApp ??
this class was a test-only class, so I don’t think it’s of use for production
end users. Why should we add it to SolrCLI?
MG>has to do with Blocking nature of your Native Random Number Generator (from
Sun or Linux)
NativePRNGBlocking will be problematic in any applications where you do not
want your application to block while the system gathers more entropy. Getting
any type of output from it could cause your application’s thread to hang.
It is fine for use in a desktop application for generating a local
cryptographic key (for example), but will almost never be okay to use in a web
MG>since we dont want webapp to hang..how to config using a non-blocking RNG ?
MG>java.security could specify securerandom.source to an unblocked source
MG>but wait devs dont have access to this file ..the Operations people do and
they wont touch it..second option:
MG>from Java CLI specify generate RNG from unblocking source
java -Djava.security.egd=file:/dev/urandom ...
(possibly update server/solr/collection1/conf for cli-test-solrcloud-start.sh)
update scripts to accommodate -Djava.security.egd=file:/dev/urandom
MG>the next call to create RNG instance will not block
SecureRandom random=SecureRandom("NativePRNG",String provider);
//warning make sure provider is listed in $JRE_HOME/lib/security/java.security
MG>P/L uwe wants us to verify we *are* using a NonBlocking RandomNumberGenerator
SecureRandomAlgorithmTesterApp will assert but for the time being we could set
it up to make sure all the executions are made non-blocking.
MG>SecureRandomAlgorithmTesterApp accepts the algorithm, the function and the
amount of data are program arguments.
MG>the 2 SecureRandomAlgorithmTesterApp features i would refactor:
MG>function should be default callback function
MG>data should be default to a constant
MG>i have seen when someone implements a provider which does not support their
JDK Providers Documentation -
This document contains the technical details of the providers that are included
in the JDK. It is assumed that readers have a strong understanding of the Java
MG>To Recap: SecureRandomAlgorithmTesterApp would be a testing tool to test:
MG>RandomNumberGenerator does indeed draw from unblocking source
MG>ensures SecureRandom algorithm is supported by providers listed in
Achterdiek 19, D-28357 Bremen
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Monday, February 12, 2018 4:27 AM
Subject: Re: SecureRandomAlgorithmTesterApp ??
From: Uwe Schindler <u...@thetaphi.de<mailto:u...@thetaphi.de>>
Sent: Sunday, February 11, 2018 6:41 PM
Subject: SecureRandomAlgorithmTesterApp ??
in Solr's Core test class is a file "SecureRandomAlgorithmTesterApp.java" in
the default package. It is also compiled, but not used anywhere. It does not
appear in Javadocs (as it's test only), but the updated weekly OpenClover
coverage report list it as a completely untested class file in the default
package. I'd like to delete it unless there is a use-case for it. Maybe let's
move it into a package, if it's of use. It seems to be a command line program
to test some SecureRandomConfigs in the JVM.
It was added by: SOLR-10338: Configure SecureRandom non blocking for tests
(Mark Miller). I think it was just some testing when SecureRandom support was
added and got accidentally committed to source tree.
MG>would it make sense to copy SecureRandomAlgorithmTesterApp as static inner
class inside org.apache.solr.util.SOLRCLI ?
GC: SolrCLI - org.apache.solr.util.SolrCLI (.java) - GrepCode Class
org.apache.solr.util.SolrCLI - Command-line utility for working with Solr
Achterdiek 19, D-28357 Bremen
To unsubscribe, e-mail:
For additional commands, e-mail: