[ 
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973787#comment-15973787
 ] 

Hoss Man commented on SOLR-10338:
---------------------------------

I don't think we should have tests that assert something happens "fast enough" 
... past experience shows that leads nothing but pain.

I think for a check like this, it's fine to just be more permissive about the 
expected types of non-blocking algorithms we might encounter -- as long as 
there's an easy work around for people on a the bleeding edge of 
new/alternative JVMs.

how about something like ...

{code}
    final String egdfile = System.getProperty("java.security.egd");
    final String allowed = System.getProperty("test.solr.allowed.securerandom");
    
    // NOTE: we're checking egdfile *BEFORE* we init a SecureRandom, since we 
want this check to
    // be as fast as possible, and if it's not correct, the SecureRandom 
constructor might block and slow us down
    if (null == allowed) {
      assertEquals("Solr tests expect a non-blocking SecureRandom to be 
configured. " +
                   "Use -Djava.security.egd=file:/dev/./urandom as a JVM option 
when running tests to bypass this check.",
                   "file:/dev/./urandom", egdfile);
    }

    final String actual = (new SecureRandom()).getAlgorithm();
    
    if (null != allowed) {
      assertEquals("SecureRandom algorithm does not match the specified 
-Dtest.solr.allowed.securerandom=" + allowed + " JVM option. " +
                   "Set -Djava.security.egd=... accordingly, or remove the 
test.solr.allowed.securerandom option",
                   allowed, actual);
    } else {
      assertTrue("SecureRandom algorithm '"+actual+"' is in use by your JVM, " +
                 "but does not match any of the known non-blocking algorithms 
that are expected. " +
                 "Please report the details of this failure (and your JVM 
vendor/version) to solr-u...@lucene.apache.org. " +
                 "You can bypass this check in the meantime by specifying 
-Dtest.solr.allowed.securerandom=" +
                 actual + " as a JVM option when running tests.",
                 // be permissive in our checks to try and account for future 
variations
                 (actual.contains("NonBlocking") || actual.contains("SHA") || 
actual.contains("DRBG")));
    }

{code}




> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to