[
https://issues.apache.org/jira/browse/SOLR-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15274730#comment-15274730
]
Hoss Man commented on SOLR-9068:
--------------------------------
bq. Why not use this patch also for non-Solaris?
Well, as miller put it in the parent issue once: mainly because the goal here
is to keep the SSL code as fast as possible since we don't actaully care about
the "correcectness" of the SSL, we just care that Solr is using SSL and doesn't
have any hardcoded http assumptions that break when SSL is enabled. So if we
can avoid wasting CPU cycles on (psuedo)randomness by having a bunch of No-Op
methods, then we might as well.
> Solaris SSL test failures when using NullSecureRandom?
> ------------------------------------------------------
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log,
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig
> was refactored so that both client & server would use it to prevent blocked
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have
> seen failures at the same spots in
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs
> the root cause appears to be intranode communication failures due to
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled
> when the SecureRandom instance returns long strings of null bytes?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
