[
https://issues.apache.org/jira/browse/SOLR-15646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421102#comment-17421102
]
Mark Robert Miller commented on SOLR-15646:
-------------------------------------------
Which by the way, is not to say I’m not interested in a technical argument. For
those that profile a lot, have 16-128 cores, run tests a lot, regardless of
that issue, this is high cost, disturbs and pollutes results, and has no
apparent value (same as SSL). This issue is in response to doing these things
and having those issues, regardless of what else has been committed.
I’m def open to the technical other side, I’m feeling there is this other issue
still leaves me in the same place and I don’t understand the comment about
proper key generation or using the correct provider. Mainly because there is no
correct provider - there are options, and varying defaults, and because it has
nothing to do with proper key generation - this controls raw byte arrays and
how easy it would be for someone to crack our tests. The only reason to block
for entropy is to make more realistic random data to make crypto more secure.
But that doesn’t change functionality or what’s being tested. What’s chosen is
the random data generation algorithm. Which returns random byte arrays. We
don’t tests the more than one that can be used because it’s an api that returns
random byte arrays. I don’t believe it should be hit, so you have 100% coverage
on every code line. I think that covers most of it. Technical against?
> Add a non secure RSAKeyPair keygen mode for tests.
> --------------------------------------------------
>
> Key: SOLR-15646
> URL: https://issues.apache.org/jira/browse/SOLR-15646
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
> Reporter: Mark Robert Miller
> Assignee: Mark Robert Miller
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
