________________________________
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
application.
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
securerandom.source=file:/dev/urandom
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 ...
./solr/cloud-dev/cli-test-solrcloud-start.sh
(possibly update server/solr/collection1/conf for cli-test-solrcloud-start.sh)
update scripts to accommodate -Djava.security.egd=file:/dev/urandom
./solr/cloud-dev/solrcloud-start-existing.sh
./solr/cloud-dev/solrcloud-start.sh
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
https://docs.oracle.com/javase/9/security/oracleproviders.htm#JSSEC-GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D
JDK Providers Documentation -
Oracle<https://docs.oracle.com/javase/9/security/oracleproviders.htm#JSSEC-GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D>
docs.oracle.com
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
java.security
MG>WDYT?
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de<http://www.thetaphi.de/>
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 ??
Hi,
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 ?
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/5.2.0/org/apache/solr/util/SolrCLI.java#SolrCLI.ApiTool
GC: SolrCLI - org.apache.solr.util.SolrCLI (.java) - GrepCode Class
Source<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/5.2.0/org/apache/solr/util/SolrCLI.java#SolrCLI.ApiTool>
grepcode.com
org.apache.solr.util.SolrCLI - Command-line utility for working with Solr
MG>WDYT?
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de<mailto:u...@thetaphi.de>
---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscr...@lucene.apache.org<mailto:dev-unsubscr...@lucene.apache.org>
For additional commands, e-mail:
dev-h...@lucene.apache.org<mailto:dev-h...@lucene.apache.org>
