[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[ https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10338: Attachment: SOLR-10338.patch Whoops ... forgot i wanted to tweak the log.info in my last patch > 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, 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
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10338:
Attachment: SOLR-10338.patch
Mihaly: my concern with your latest patch (other then a small missues of
securityEgdValue instead of algorithm in the final assert) is that it doesn't
check the "test.solr.allowed.securerandom" sys property until *AFTER* calling
{{System.setProperty("java.security.egd",...)}} ... if the user has gone out of
their way to say "let me use the secure random i want" then we shouldn't be
mucking with their source of randomness at all.
Attached patch reorders things a bit ... i've only done cursory testing but i
think it's correct.
what do you think?
> 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, 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
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[ https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaly Toth updated SOLR-10338: --- Attachment: SOLR-10338.patch I tried to keep it simple, that is why I used only a flag to skip this part. On the other hand, I can accept that this way the users have multiple options without the need to touch the code. Also adjusted the logging as you asked for. I have uploaded a new patch for these. > 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, 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
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihaly Toth updated SOLR-10338:
---
Attachment: SOLR-10338.patch
I tried again setting {{java.security.egd}} from a class itself. It is possible
to set it, and it does have an effect on the algorithm selected given that the
Sun security provider is loaded after that. Please see my opening comment on
this Jira for code snippets.
So I believe it is possible. The other question is if it is needed. The only
motivation now are other projects that are depending on {{SolrTestCaseJ4}}.
With setting the property if it is unset, there is a chance that those projects
are not broken.
In Solr test however I would not rely solely on this solution because this is
not bullet proof. If any other test not subclassing {{SolrTestCaseJ4}} AND
using directly or indirectly {{SecureRandom}} would run before
{{SolrTestCaseJ4}} subclassed tests then all these later tests would fail. This
is because the algorithm is decided on first usage of {{SecureRandom}}. I did a
test run having only setting the property in setup and I have got couple of
failures.
The attached patch uses {{test.solr.allow.any.securerandom}} system property to
allow validation of the algorithm defaulting to true. In case of algorithm
verification I blacklisted {{NativePRNG}} and {{NativePRNGBlocking}}. According
to
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SUNProvider
those are the algorithms using {{/dev/random}} in one way or another.
Regarding the question on how stable it is to overwrite this property from code
I found no mentioning of any limitation where the property could be set. Among
other page I read the javadoc of
https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/classes/sun/security/provider/NativePRNG.java
. So I do not think this behaviour would change in any future versions of Java
8. NativePRNG in Java 9 is only a skeleton implementation. And we have the test
suite as a last resort to tell if such unexpected event occured.
> 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, 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
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[ https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaly Toth updated SOLR-10338: --- Attachment: SOLR-10338.patch How about such a fix? In case randomness is blocking Solr tests will time out. > 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: master (7.0), 6.6 > > 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
[jira] [Updated] (SOLR-10338) Configure SecureRandom non blocking for tests.
[ https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-10338: --- Summary: Configure SecureRandom non blocking for tests. (was: Configure SecureRandom non blocking) > 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: 4.9, 6.0 > > Attachments: 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
