[
https://issues.apache.org/jira/browse/SOLR-9609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-9609:
---------------------------------
Attachment: SOLR-9609.patch
So here's a first cut at what it would take to move this to security.json (hey,
it compiles, but it's _completely_ untested).
The reason I'm putting this up is that putting this value in security.json
starts to get...messy and I'm wondering if the elegance of putting this in
security.json outweighs the messiness.
The basic problem is that CryptoKeys doesn't have access to SecurityConfig. So
we can either pass CoreContainer down to CryptoKeys (yuuuuck, talk about
architectural badness) or have CryptoKeys take a length for this buffer.
The second option requires that the caller get the new value from the
SecurityConfig object if it's different than the default and pass that in to
the c'tor. Which I made the PKIAuthenticationPlugin do.
Unless we make the default CryptoKeys c'tor private, any new classes using
CryptoKeys has to remember to get the value from security.json which could be
forgotten. I suppose we can just deprecate the default c'tor and then caveat
emptor. My guess is that just making the default c'tor private is unacceptable
as it breaks back-compat.
All this to allow different buffer lengths to be chosen. So is it really worth
it? It seems we have several options:
1> go ahead and put it in security.json because it's the right thing to do.
2> allow it to be configurable with a sysvar, which is much easier.
3> hard code it to some future-friendly value like 4096. This assumes that
having a value larger than necessary is OK.
Or am I missing some way to get around this mess?
P.S. there's a nocommit in there (should we really have a main method in
CryptoKeys?) and I'll take out a change in the PKI test unless we deprecate the
default c'tor in CryptoKeys if we decide to put this in security.json after all.
> Change hard-coded keysize from 512 to 1024
> ------------------------------------------
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Jeremy Martini
> Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, SOLR-9609.patch,
> solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password
> in the configuration file, we extended JdbcDataSource to create our own
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
> <dataSource type="com.foo.FooDataSource" driver="oracle.jdbc.OracleDriver"
> url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser"
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the
> password. However, this seems to cause an issue when we try use Solr in a
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
> KeyPairGenerator keyGen = null;
> try {
> keyGen = KeyPairGenerator.getInstance("RSA");
> } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
> }
> keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt
> it, and now everything seems to work great.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
