From: Uwe Schindler <u...@thetaphi.de>
Sent: Monday, February 12, 2018 2:31 AM
To: dev@lucene.apache.org
Subject: RE: SecureRandomAlgorithmTesterApp ??

Hi Martin,

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 
SecureRandom Algorithm

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 




Uwe Schindler

Achterdiek 19, D-28357 Bremen


eMail: u...@thetaphi.de

From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Monday, February 12, 2018 4:27 AM
To: dev@lucene.apache.org
Subject: Re: SecureRandomAlgorithmTesterApp ??


From: Uwe Schindler <u...@thetaphi.de<mailto:u...@thetaphi.de>>
Sent: Sunday, February 11, 2018 6:41 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
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



Uwe Schindler
Achterdiek 19, D-28357 Bremen
eMail: u...@thetaphi.de<mailto:u...@thetaphi.de>

To unsubscribe, e-mail: 
For additional commands, e-mail: 

Reply via email to