[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[ https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762263#comment-17762263 ] Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:31 AM: - Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read the details here. Interestingly when we did CASSANDRA-18124 changes, we did talk about this exact issue- What to do with password check for the JKS based keystores- as you would be able to notice in that ticket, !image-2023-09-05-21-13-06-602.png! So at that point we decided to go with enforcing the JKS keystores to have the password. However, based on what [~andrew.tolbert] mentions here about PKCS12 keystores generated without a password via OpenSSL makes a valid case in terms of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we read keystores without a password that the authenticity of the data can't be verified without the password and that made me think about the password's necessity for the JKS keystores. So while from the operational standpoint I would still think we should specify password for the keystore, if the tooling from OpenSSL allows passwordless keystore creation, we can make this exception to cover for it. For the Truststores, however I think we can live without password since it is just a collection of `public keys` and authenticity like keystore may be considered optional. That was the primary thinking that resulted into the state of code that we have prior to this change. One challenge, if I recollect it right, I ran into was- in the YAML file I could not simulate the `null` password because there was a default of `empty string` somewhere (most likely EncryptionOptions.java). Based on what I see in your changes that got merged- I see that you are testing for `null` case from the code and not from the YAML. Just something to double-click on and see if there is anything we need to do more. If practically YAML file makes it difficult to have a possibility of `null` password, the CASSANDRA-18124 should not create a backward incompatibility issue in my opinion. All-in-all, I don't mind having to support keystores without passwords and don't feel it may be worth requiring passwords for the truststores :) was (Author: maulin.vasavada): Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read the details here. Interestingly when we did CASSANDRA-18124 changes, we did talk about this exact issue- What to do with password check for the JKS based keystores- as you would be able to notice in that ticket, !image-2023-09-05-21-13-06-602.png! So at that point we decided to go with enforcing the JKS keystores to have the password. However, based on what [~andrew.tolbert] mentions here about PKCS12 keystores generated without a password via OpenSSL makes a valid case in terms of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we read keystores without a password that the authenticity of the data can't be verified without the password and that made me think about the password's necessity for the JKS keystores. So while from the operational standpoint I would still think we should specify password for the keystore, if the tooling from OpenSSL allows passwordless keystore creation, we can make this exception to cover for it. For the Truststores, however I think we can live without password since it is just a collection of `public keys` and authenticity like keystore may be considered optional. That was the primary thinking that resulted into the state of code that we have prior to this change. One challenge, if I recollect it right, I ran into was- in the YAML file I could not simulate the `null` password because there was a default of `empty string` somewhere (most likely EncryptionOptions.java). Based on what I see in your changes that got merged- I see that you are testing for `null` case from the code and not from the YAML. Just something to double-click on and see if there is anything we need to do more. All-in-all, I don't mind having to support keystores without passwords and don't feel it may be worth requiring passwords for the truststores :) > Empty keystore_password no longer allowed on encryption_options > --- > > Key: CASSANDRA-18778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18778 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Andy Tolbert >Assignee: Andy Tolbert >Priority: Normal > Fix For: 4.1.4, 5.0 > > Attachments: image-2023-09-05-21-13-06-602.png > > > After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible > to set an empty
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762263#comment-17762263
]
Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:28 AM:
-
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we
read keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception
to cover for it.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
was (Author: maulin.vasavada):
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762263#comment-17762263
]
Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:27 AM:
-
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
was (Author: maulin.vasavada):
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). However, if your
changes are tested already and merged I guess you have a test case for
differentiating `null` vs `empty string` (will check your PR).
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762263#comment-17762263
]
Maulin Vasavada commented on CASSANDRA-18778:
-
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). However, if your
changes are tested already and merged I guess you have a test case for
differentiating `null` vs `empty string` (will check your PR).
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
>
[jira] [Updated] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada updated CASSANDRA-18778:
Attachment: image-2023-09-05-21-13-06-602.png
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747172#comment-17747172
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~brandon.williams] and [~smiklosovic]. Can you please provide the PR
approval/merge and move this ticket to the appropriate state?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747165#comment-17747165
]
Maulin Vasavada commented on CASSANDRA-18428:
-
For j17 unit tests on the CI above, I see below test failures, due to failure
to create certs. I guess that is as per discussed on some other thread due to
deprecated jdk classes.
{noformat}
Testcase:
testServerSocketShouldUseKeystore(org.apache.cassandra.security.SSLFactoryTest)-.jdk17:
Caused an ERROR
[junit-timeout] Could not initialize class
org.apache.cassandra.security.SSLFactoryTest
[junit-timeout] java.lang.NoClassDefFoundError: Could not initialize class
org.apache.cassandra.security.SSLFactoryTest
[junit-timeout] at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[junit-timeout] at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
[junit-timeout] at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
[junit-timeout] Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.RuntimeException: failed to create test certs [in thread "main"]
[junit-timeout] at
org.apache.cassandra.security.SSLFactoryTest.(SSLFactoryTest.java:70){noformat}
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747086#comment-17747086
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/25/23 5:26 PM:
--
Thanks [~mmuzaf] for approving the
[PR#2507.|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
was (Author: maulin.vasavada):
Thanks [~mmuzaf] for approving the
[PR#2507|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747086#comment-17747086
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/25/23 5:26 PM:
--
Thanks [~mmuzaf] for approving the
[PR#2507|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
was (Author: maulin.vasavada):
Thanks [~mmuzaf] for approving the
[PR#2507|[https://github.com/apache/cassandra/pull/2507].] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17747086#comment-17747086
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~mmuzaf] for approving the
[PR#2507|[https://github.com/apache/cassandra/pull/2507].] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17746621#comment-17746621
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~mmuzaf] The reason I opened a new PR is because I rebuilt the latest
trunk locally, made sure I generate idea files ant command before I open the
IntelliJ IDE and then made changes manually again and verified that all the
style check comments you provided are addressed. Now, since anyway I closed the
older PR we can continue with the new PR. Hope thats fine. Thanks for the CI
run.
For the Jira status, what should I change to reflect its ready? Currently I
don't seem to have access to change the 'Status' field.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:15 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
And +1 on the sdkman. I love it too.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710356#comment-17710356
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:13 AM:
---
-PR: [https://github.com/apache/cassandra/pull/2269]-
See the new PR: [https://github.com/apache/cassandra/pull/2507]
was (Author: maulin.vasavada):
PR: [https://github.com/apache/cassandra/pull/2269]
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745852#comment-17745852
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files].] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:11 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files].] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:12 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new [PR
2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:12 AM:
---
[~mmuzaf] I will close the older PR and opened a new [PR
2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745270#comment-17745270
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Also, let us take the password encryption in the local files separately, I
think that has been a topic of interest in the past also.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17745268#comment-17745268
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Hi [~mmuzaf] Thanks for the review. Will check on the suggestions soon. One
traditional issue I have faced with the changes is the 'style issue'. Currently
when I run the `ant checkstyle` it successfully completes it without errors, so
not sure how can I catch those errors before I can raise a PR.
In the past I had similar challenge and something with JDK11 was found to be an
issue skipping the actual style check. Now I am not sure what could be the
issue.
{noformat}
checkstyle:
[checkstyle] Running Checkstyle 10.8.1 on 2201 files
BUILD SUCCESSFUL
Total time: 33 seconds{noformat}
Let me see if I see anything different with a fresh local build.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17726739#comment-17726739
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~edimitrova] [~djoshi] [~stefan.miklosovic] I know you guys must be heads down
busy but just wanted to ^^^bump^^^ this ticket since its a low-hanging fruit.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715192#comment-17715192
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~edimitrova] Does this sound like a straightforward change to be considered
for a quick review/merge?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-18428:
---
Assignee: Maulin Vasavada
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713218#comment-17713218 ] Maulin Vasavada commented on CASSANDRA-18124: - Thank you both [~smiklosovic] and [~maedhroz] > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 5.0, 4.1.2 > > Time Spent: 11h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711601#comment-17711601 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] I prepared the backport for this ticket for 4.1 branch. Please review [this PR-2273|https://github.com/apache/cassandra/pull/2273] > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711098#comment-17711098 ] Maulin Vasavada commented on CASSANDRA-18124: - Will prepare 4.1 patch and picked-up Caleb's suggestions on the NEWS.txt. Now I guess one comment left to be resolved. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17711098#comment-17711098 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 4/11/23 7:52 PM: -- Will prepare 4.1 patch and picked-up Caleb's suggestions on the NEWS.txt. Now I guess one comment left to be resolved. It shows conflict for NEWS.txt with trunk so I'd have to take the latest copy and reapply the latest changes on it once we close on all the comments. was (Author: maulin.vasavada): Will prepare 4.1 patch and picked-up Caleb's suggestions on the NEWS.txt. Now I guess one comment left to be resolved. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada updated CASSANDRA-18428:
Description:
We have {{equals and hashCode}} methods in
[EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
object but not (overridden/extended) in
[ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
Code is using the EncryptionOptions as the key in the
[ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
in the SSLFactory.java. Hence technically we must have a equals/hashCode
override in the ServerEncryptionOptions to account for fields that matter
additionally (e.g. outbound_keystore/password).
We discussed this over the [cassandra-dev slack
channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and it
seems agreeable to make this change.
was:
We have {{equals and hashCode}} methods in
[EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
object but not (overridden/extended) in
[ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
Code is using the EncryptionOptions as the key in the
[ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
in the SSLFactory.java. Hence technically we must have a equals/hashCode
override in the ServerEncryptionOptions to account for fields that matter
additionally (e.g. outbound_keystore/password).
We discussed this over the cassandra-dev slack channel and it seems agreeable
to make this change.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710356#comment-17710356
]
Maulin Vasavada commented on CASSANDRA-18428:
-
PR: [https://github.com/apache/cassandra/pull/2269]
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the cassandra-dev slack channel and it seems agreeable
> to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710349#comment-17710349 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] Finally I got my IntelliJ 2023 working! Let me know if you want me to backport to 4.1. [~maedhroz] I added a note in the NEWS.txt, please review and see if you have any comments. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710307#comment-17710307 ] Maulin Vasavada commented on CASSANDRA-18124: - [~maedhroz] I'll modify the NEWS.txt as per the PR suggestion. I got distracted due to 2023 IntelliJ forced update that killed my workspace (still broken) but the NEWS.txt change doesn't depend on my workspace's stability so I can make it separately. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710306#comment-17710306 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 4/10/23 8:41 PM: -- [~smiklosovic] This might have conflict with 4.1 because the trunk's compilation on examples/ssl-factory was broken and originally you fixed it in your branch and I picked up the same changes in my PR. I made sure in my PR I have a separate commit just to fix that compilation issue on the trunk to clearly see what was needed for that vs my actual intended changes for this ticket. Yes based on CASSANDRA-17513 changes the examples/ssl-factory needed to have the changes it didn't have I think. was (Author: maulin.vasavada): [~smiklosovic] This might have conflict with 4.1 because the trunk's compilation on examples/ssl-factory was broken and originally you fixed it in your branch and I picked up the same changes in my PR. I made sure in my PR I have a separate commit just to fix that compilation issue on the trunk to clearly see what was needed for that vs my actual intended changes for this ticket. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710306#comment-17710306 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] This might have conflict with 4.1 because the trunk's compilation on examples/ssl-factory was broken and originally you fixed it in your branch and I picked up the same changes in my PR. I made sure in my PR I have a separate commit just to fix that compilation issue on the trunk to clearly see what was needed for that vs my actual intended changes for this ticket. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
Maulin Vasavada created CASSANDRA-18428:
---
Summary: Implement/override equals and hashCode methods in the
ServerEncryptionOptions class
Key: CASSANDRA-18428
URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
Project: Cassandra
Issue Type: Improvement
Reporter: Maulin Vasavada
We have {{equals and hashCode}} methods in
[EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
object but not (overridden/extended) in
[ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
Code is using the EncryptionOptions as the key in the
[ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
in the SSLFactory.java. Hence technically we must have a equals/hashCode
override in the ServerEncryptionOptions to account for fields that matter
additionally (e.g. outbound_keystore/password).
We discussed this over the cassandra-dev slack channel and it seems agreeable
to make this change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707072#comment-17707072 ] Maulin Vasavada commented on CASSANDRA-18124: - Hi [~rtib] Please confirm with the latest PR if the changes look good based on your testing. [~smiklosovic] I've resolved your comment on the PR, let me know if you want me to start the circleCI or you would kick it off. Thanks > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706569#comment-17706569 ] Maulin Vasavada commented on CASSANDRA-18124: - Hi [~rtib] and [~smiklosovic] I made changes suggested above and on the PR for the formatting fix. Raised a new PR, since I wanted to make sure I can see the formatting changes clearly. Can you please test/review [https://github.com/apache/cassandra/pull/2253] ? Thanks. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699885#comment-17699885 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/29/23 7:04 PM: -- [~smiklosovic] Here you go [-https://github.com/apache/cassandra/pull/2225-] was (Author: maulin.vasavada): [~smiklosovic] Here you go https://github.com/apache/cassandra/pull/2225 > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704370#comment-17704370 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/23/23 9:39 PM: -- Thanks [~rtib] for the review. I can update the cassandra yaml to have the PEM example in comments. Also I'll try to check on the Nodetool output. I fixed the issue of getting truststore warning for the PEM and made truststore password also nullable but this warning I need to check. Earlier it came because of defaults and the fallback of `key_password` to `keystore_password` in the absence of the prior, now it could be the same reason. One option is - avoid logging a warning in case both the values are same since technically it doesn't create any issue ONLY in case they are different we should log a warning. What do you think? Meanwhile [~smiklosovic] can we get any additional PR reviews to have more eyes on this ? was (Author: maulin.vasavada): Thanks [~rtib] for the review. I can update the cassandra yaml to have the PEM example in comments. Also I'll try to check on the Nodetool output. I fixed the issue of getting truststore warning for the PEM and made truststore password also nullable but this warning I need to check. Earlier it came because of defaults and the fallback of `key_password` to `keystore_password` in the absence of the prior, now it could be the same reason. Meanwhile [~smiklosovic] can we get any additional PR reviews to have more eyes on this ? > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704370#comment-17704370 ] Maulin Vasavada commented on CASSANDRA-18124: - Thanks [~rtib] for the review. I can update the cassandra yaml to have the PEM example in comments. Also I'll try to check on the Nodetool output. I fixed the issue of getting truststore warning for the PEM and made truststore password also nullable but this warning I need to check. Earlier it came because of defaults and the fallback of `key_password` to `keystore_password` in the absence of the prior, now it could be the same reason. Meanwhile [~smiklosovic] can we get any additional PR reviews to have more eyes on this ? > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 20m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699885#comment-17699885 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/16/23 9:01 PM: -- [~smiklosovic] Here you go https://github.com/apache/cassandra/pull/2225 was (Author: maulin.vasavada): [~smiklosovic] Here you go with [a PR|https://github.com/instaclustr/cassandra/pull/49] on the instaclustr/cassandra. Let us review that and I can start porting those changes to 4.1/trunk on apache/cassandra. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699885#comment-17699885 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] Here you go with [a PR|https://github.com/instaclustr/cassandra/pull/49] on the instaclustr/cassandra. Let us review that and I can start porting those changes to 4.1/trunk on apache/cassandra. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699821#comment-17699821 ] Maulin Vasavada commented on CASSANDRA-18124: - Sure, soon enough. I was on instaclustr branch (inherited from the other issue's discussion). I can quickly raise a PR there while I work on the 4.1 patch as per Brandon's suggestion. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699145#comment-17699145 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/11/23 1:18 AM: -- So far it looks like 1st option is more convoluted. 2nd option is much cleaner and simple changes. If we fail to provide `keystore_password` for the JKS, it will fail with the new changes (throws NPE since the FileBasedSslContextFactory.java doesn't expect null for the password). I can add validation in the FileBasedSslContextFactory for the null keystore password to avoid NPE. was (Author: maulin.vasavada): So far it looks like 1st option is more convoluted. 2nd option is much cleaner and simple changes. If we fail to provide `keystore_password` for the JKS, it will fail with the new changes (throws NPE since the FileBasedSslContextFactory.java) doesn't expect null for the password. I can add validation in the FileBasedSslContextFactory for the null keystore password to avoid NPE. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699145#comment-17699145 ] Maulin Vasavada commented on CASSANDRA-18124: - So far it looks like 1st option is more convoluted. 2nd option is much cleaner and simple changes. If we fail to provide `keystore_password` for the JKS, it will fail with the new changes (throws NPE since the FileBasedSslContextFactory.java) doesn't expect null for the password. I can add validation in the FileBasedSslContextFactory for the null keystore password to avoid NPE. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699105#comment-17699105 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/10/23 8:36 PM: -- Thanks [~brandon.williams] . [~smiklosovic] While modifying the code to allow null password configuration for the PEM I am running into a challenge due to the default logic to fallback to `keystore_password` configuration in case `key_password` configuration (created for the PEM) is null/missing. Due to that fallback logic we have to change default for the `keystore_password` also to be null (specifically in EncryptionOptions.java). I think we have two options- # Drop the fallback logic reading the `keystore_password` in case of PEM keys. ## This fallback logic was done primarily to support a use-case for PEM keys provided in a file with existing `keystore` configuration in which case it also makes sense to continue read the key password from the `keystore_password`configuration. # Make `keystore_password` nullable configuration which means removing the default value injected by EncryptionOptions.java ## I think we can make this nullable since practically operators might not have JKS keystores without the passwords except for a missed-configuration use-case AND for PEM it makes perfect sense to allow null password for the unencrypted keys. ## However, since we are changing the default for an older configuration, we have to give more thoughts on its effect on existing systems. Let me see what 2nd option entails (in terms of tests etc) while you provide you thoughts on this. was (Author: maulin.vasavada): Thanks [~brandon.williams] . [~smiklosovic] While modifying the code to allow null password configuration for the PEM I am running into a challenge due to the default logic to fallback to `keystore_password` configuration in case `key_password` configuration (created for the PEM) is null/missing. Due to that fallback logic we have to change default for the `keystore_password` also to be null (specifically in EncryptionOptions.java). I think we have two options- # Drop the fallback logic reading the `keystore_password` in case of PEM keys. ## This fallback logic was done primarily to support a use-case for PEM keys provided in a file with existing `keystore` configuration in which case it also makes sense to continue read the key password from the `keystore_password`configuration. # Make `keystore_password` nullable configuration which means removing the default value injected by EncryptionOptions.java ## I think we can make this nullable since practically operators might not have JKS keystores with the passwords except for a missed-configuration use-case AND for PEM it makes perfect sense to allow null password for the unencrypted keys. ## However, since we are changing the default for an older configuration, we have to give more thoughts on its effect on existing systems. Let me see what 2nd option entails (in terms of tests etc) while you provide you thoughts on this. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699105#comment-17699105 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/10/23 8:35 PM: -- Thanks [~brandon.williams] . [~smiklosovic] While modifying the code to allow null password configuration for the PEM I am running into a challenge due to the default logic to fallback to `keystore_password` configuration in case `key_password` configuration (created for the PEM) is null/missing. Due to that fallback logic we have to change default for the `keystore_password` also to be null (specifically in EncryptionOptions.java). I think we have two options- # Drop the fallback logic reading the `keystore_password` in case of PEM keys. ## This fallback logic was done primarily to support a use-case for PEM keys provided in a file with existing `keystore` configuration in which case it also makes sense to continue read the key password from the `keystore_password`configuration. # Make `keystore_password` nullable configuration which means removing the default value injected by EncryptionOptions.java ## I think we can make this nullable since practically operators might not have JKS keystores with the passwords except for a missed-configuration use-case AND for PEM it makes perfect sense to allow null password for the unencrypted keys. ## However, since we are changing the default for an older configuration, we have to give more thoughts on its effect on existing systems. Let me see what 2nd option entails (in terms of tests etc) while you provide you thoughts on this. was (Author: maulin.vasavada): Thanks [~brandon.williams] . [~smiklosovic] While modifying the code to allow null password configuration for the PEM I am running into a challenge that we have a logic to fallback to `keystore_password` configuration in case `key_password` configuration (created for the PEM). Due to that fallback logic we have to change default for the `keystore_password` also to be null (specifically in EncryptionOptions.java). I think we have two options- # Drop the fallback logic reading the `keystore_password` in case of PEM keys. ## This fallback logic was done primarily to support a use-case for PEM keys provided in a file with existing `keystore` configuration in which case it also makes sense to continue read the key password from the `keystore_password`configuration. # Make `keystore_password` nullable configuration which means removing the default value injected by EncryptionOptions.java ## I think we can make this nullable since practically operators might not have JKS keystores with the passwords except for a missed-configuration use-case AND for PEM it makes perfect sense to allow null password for the unencrypted keys. ## However, since we are changing the default for an older configuration, we have to give more thoughts on its effect on existing systems. Let me see what 2nd option entails (in terms of tests etc) while you provide you thoughts on this. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699105#comment-17699105 ] Maulin Vasavada commented on CASSANDRA-18124: - Thanks [~brandon.williams] . [~smiklosovic] While modifying the code to allow null password configuration for the PEM I am running into a challenge that we have a logic to fallback to `keystore_password` configuration in case `key_password` configuration (created for the PEM). Due to that fallback logic we have to change default for the `keystore_password` also to be null (specifically in EncryptionOptions.java). I think we have two options- # Drop the fallback logic reading the `keystore_password` in case of PEM keys. ## This fallback logic was done primarily to support a use-case for PEM keys provided in a file with existing `keystore` configuration in which case it also makes sense to continue read the key password from the `keystore_password`configuration. # Make `keystore_password` nullable configuration which means removing the default value injected by EncryptionOptions.java ## I think we can make this nullable since practically operators might not have JKS keystores with the passwords except for a missed-configuration use-case AND for PEM it makes perfect sense to allow null password for the unencrypted keys. ## However, since we are changing the default for an older configuration, we have to give more thoughts on its effect on existing systems. Let me see what 2nd option entails (in terms of tests etc) while you provide you thoughts on this. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698660#comment-17698660 ] Maulin Vasavada edited comment on CASSANDRA-18124 at 3/10/23 12:39 AM: --- [~smiklosovic] I'll take this. Sorry last couple of weeks have been crazy. was (Author: maulin.vasavada): [~smiklosovic] I'll take this. Sorry last couple of weeks has been crazy. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698661#comment-17698661 ] Maulin Vasavada commented on CASSANDRA-18124: - One question- Since the trunk was broken for example/ssl-factory, what should be the base I. can use to build for this if the trunk is still broken? > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698660#comment-17698660 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] I'll take this. Sorry last couple of weeks has been crazy. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maulin Vasavada reassigned CASSANDRA-18124: --- Assignee: Maulin Vasavada > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694218#comment-17694218
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/27/23 11:21 PM:
---
Sure [~smiklosovic] I think we can use the 18124 ticket. So my assumption is
that once 18124 gets merged (with the suggested isEmpty check) to the trunk we
can close this ticket as well, correct?
was (Author: maulin.vasavada):
Sure [~smiklosovic] I think we can use the 18124 ticket. So my assumption is
that once 18124 gets merged to the trunk we can close this ticket as well,
correct?
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694218#comment-17694218
]
Maulin Vasavada commented on CASSANDRA-18270:
-
Sure [~smiklosovic] I think we can use the 18124 ticket. So my assumption is
that once 18124 gets merged to the trunk we can close this ticket as well,
correct?
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693394#comment-17693394
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/25/23 1:25 AM:
--
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this
line|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMReader.java#L103]
to check for the below condition OR do you want me to raise a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
And just for the reference, when I try to output public key from an encrypted
PEM with password size of 2 characters I get the following error. It is
interesting that it doesn't prevent me to generate the encrypted PEM with
password of less than 4 characters but fails later.
{noformat}
command: openssl rsa -in encrypted-keypair2.pem -pubout -out public-key.pem
libressl/libressl-3.3/crypto/ui/ui_lib.c:782:You must type in 4 to 1023
characters{noformat}
was (Author: maulin.vasavada):
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this
line|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMReader.java#L103]
to check for the below condition OR do you want me to raise a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
And just for the reference, when I try to output public key from an encrypted
PEM with password size of 2 characters I get the following error-
{noformat}
command: openssl rsa -in encrypted-keypair2.pem -pubout -out public-key.pem
libressl/libressl-3.3/crypto/ui/ui_lib.c:782:You must type in 4 to 1023
characters{noformat}
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
>
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693394#comment-17693394
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/25/23 1:24 AM:
--
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this
line|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMReader.java#L103]
to check for the below condition OR do you want me to raise a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
And just for the reference, when I try to output public key from an encrypted
PEM with password size of 2 characters I get the following error-
{noformat}
command: openssl rsa -in encrypted-keypair2.pem -pubout -out public-key.pem
libressl/libressl-3.3/crypto/ui/ui_lib.c:782:You must type in 4 to 1023
characters{noformat}
was (Author: maulin.vasavada):
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this line|#L103]?] to check for the below condition OR do you want me to raise
a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
And just for the reference, when I try to output public key from an encrypted
PEM with password size of 2 characters I get the following error-
{noformat}
command: openssl rsa -in encrypted-keypair2.pem -pubout -out public-key.pem
libressl/libressl-3.3/crypto/ui/ui_lib.c:782:You must type in 4 to 1023
characters{noformat}
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693394#comment-17693394
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/25/23 1:22 AM:
--
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this line|#L103]?] to check for the below condition OR do you want me to raise
a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
And just for the reference, when I try to output public key from an encrypted
PEM with password size of 2 characters I get the following error-
{noformat}
command: openssl rsa -in encrypted-keypair2.pem -pubout -out public-key.pem
libressl/libressl-3.3/crypto/ui/ui_lib.c:782:You must type in 4 to 1023
characters{noformat}
was (Author: maulin.vasavada):
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this line|#L103]?] to check for the below condition OR do you want me to raise
a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693394#comment-17693394
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/25/23 1:21 AM:
--
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4 characters, hence I
feel it should be safe to make the change to check for !isEmpty() instead of
non null in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this line|#L103]?] to check for the below condition OR do you want me to raise
a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
was (Author: maulin.vasavada):
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4, hence I feel it
should be safe to make the change to check for !isEmpty() instead of non null
in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this
line|[https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMReader.java#L103]?]
to check for the below condition OR do you want me to raise a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693395#comment-17693395 ] Maulin Vasavada commented on CASSANDRA-18124: - SO [~frankgh] Did we make any progress on this? Do you want my help on anything? > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug >Reporter: Tibor Repasi >Priority: Normal > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693394#comment-17693394
]
Maulin Vasavada commented on CASSANDRA-18270:
-
Based on my research so far the PEM key generation - it fails to output public
key from the encrypted PEM if the password is less than 4, hence I feel it
should be safe to make the change to check for !isEmpty() instead of non null
in the PEMReader to determine if the PEM is encrypted or not.
So what should be the next step, [~smiklosovic] ? I made the change locally and
all the tests are passing now, do you want to just make it on your branch at
[this
line|[https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMReader.java#L103]?]
to check for the below condition OR do you want me to raise a PR?
{code:java}
if (!StringUtils.isEmpty(keyPassword)) {code}
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693380#comment-17693380
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/24/23 11:57 PM:
---
Okay, I think I found the issue. In 4.1 we had
[this|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108-L111]
code which used to default the keyPassword to keystore_password in case
keyPassword was null/empty AND that helped make sure that in the test case, for
the unencrypted PEM key the password is null. Hence it would go in the else
part of [this if statement
|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMReader.java#L103]and
work correctly. Now in the latest code that equivalent logic is not present
for defaulting keyPassword to keystore_password in case of empty as per
[this|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108]
code.
One solution would be to check for isEmpty() in the PEMReader instead of just
non null and that should fix this.
In JKS based keystores the passwords could be empty strings vs null. However,
In case of PEM files I feel it should be safe to consider empty string as null
password. Does that make sense, then I can change the PEMReader accordingly.
was (Author: maulin.vasavada):
Okay, I think I found the issue. In 4.1 we had
[this|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108-L111]
code which used to default the keyPassword to keystore_password in case
keyPassword was null/empty AND that helped make sure that in the test case, for
the unencrypted PEM key the password is null. Hence it would go in the else
part of [this if statement
|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMReader.java#L103]and
work correctly. Now in the latest code that equivalent logic is not present
for defaulting keyPassword to keystore_password in case of empty as per
[this|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108]
code.
One solution would be to check for isEmpty() in the PEMReader instead of just
non null and that should fix this.
In JKS based keystores the passwords could be empty strings vs null. In case of
PEM files I feel it should be safe to consider empty string as null password.
Does that make sense, then I can change the PEMReader accordingly.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit]
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693380#comment-17693380
]
Maulin Vasavada commented on CASSANDRA-18270:
-
Okay, I think I found the issue. In 4.1 we had
[this|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108-L111]
code which used to default the keyPassword to keystore_password in case
keyPassword was null/empty AND that helped make sure that in the test case, for
the unencrypted PEM key the password is null. Hence it would go in the else
part of [this if statement
|https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/security/PEMReader.java#L103]and
work correctly. Now in the latest code that equivalent logic is not present
for defaulting keyPassword to keystore_password in case of empty as per
[this|https://github.com/instaclustr/cassandra/blob/CASSANDRA-18264-trunk-followup/src/java/org/apache/cassandra/security/PEMBasedSslContextFactory.java#L108]
code.
One solution would be to check for isEmpty() in the PEMReader instead of just
non null and that should fix this.
In JKS based keystores the passwords could be empty strings vs null. In case of
PEM files I feel it should be safe to consider empty string as null password.
Does that make sense, then I can change the PEMReader accordingly.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693324#comment-17693324
]
Maulin Vasavada commented on CASSANDRA-18270:
-
Okay, I get to the error now after using your branch. Let me check.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693301#comment-17693301
]
Maulin Vasavada commented on CASSANDRA-18270:
-
let me try with your branch -
[https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup]
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693298#comment-17693298
]
Maulin Vasavada commented on CASSANDRA-18270:
-
>From the 'ant build' in the examples/ssl-factory also I get the same build
>errors.
{noformat}
cassandra/examples/ssl-factory/build.xml
init:
[mkdir] Created dir:
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/build/test/classes
build:
[javac] Compiling 2 source files to
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/build/classes
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:152:
error: cannot find symbol
[javac] keystore =
getString(EncryptionOptions.ConfigKey.KEYSTORE.toString(), KEYSTORE_PATH_VALUE);
[javac] ^
[javac] symbol: variable keystore
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:153:
error: cannot find symbol
[javac] keystore_password =
getValueFromEnv(KEYSTORE_PASSWORD_ENV_VAR_NAME,
[javac] ^
[javac] symbol: variable keystore_password
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:155:
error: cannot find symbol
[javac] truststore =
getString(EncryptionOptions.ConfigKey.TRUSTSTORE.toString(),
TRUSTSTORE_PATH_VALUE);
[javac] ^
[javac] symbol: variable truststore
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:156:
error: cannot find symbol
[javac] truststore_password =
getValueFromEnv(TRUSTSTORE_PASSWORD_ENV_VAR_NAME,
[javac] ^
[javac] symbol: variable truststore_password
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:169:
error: cannot find symbol
[javac] keystore =
getString(EncryptionOptions.ConfigKey.KEYSTORE.toString(), KEYSTORE_PATH_VALUE);
[javac] ^
[javac] symbol: variable keystore
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:170:
error: cannot find symbol
[javac] keystore_password =
getValueFromEnv(getString(ConfigKeys.KEYSTORE_PASSWORD_ENV_VAR,
[javac] ^
[javac] symbol: variable keystore_password
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:172:
error: cannot find symbol
[javac] truststore =
getString(EncryptionOptions.ConfigKey.TRUSTSTORE.toString(),
TRUSTSTORE_PATH_VALUE);
[javac] ^
[javac] symbol: variable truststore
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsSslContextFactory.java:173:
error: cannot find symbol
[javac] truststore_password =
getValueFromEnv(getString(ConfigKeys.TRUSTSTORE_PASSWORD_ENV_VAR,
[javac] ^
[javac] symbol: variable truststore_password
[javac] location: class KubernetesSecretsSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsPEMSslContextFactory.java:168:
error: cannot find symbol
[javac] checkedExpiry = pemBasedSslContextFactory.checkedExpiry;
[javac] ^
[javac] symbol: variable checkedExpiry
[javac] location: class KubernetesSecretsPEMSslContextFactory
[javac]
/Users/mvasavada/gitrepobase/cassandra/examples/ssl-factory/src/org/apache/cassandra/security/KubernetesSecretsPEMSslContextFactory.java:168:
error: cannot find symbol
[javac] checkedExpiry = pemBasedSslContextFactory.checkedExpiry;
[javac] ^
[javac] symbol: variable checkedExpiry
[javac] location: variable pemBasedSslContextFactory of type
PEMBasedSslContextFactory
[javac] 10 errors{noformat}
> ssl-factory demo in examples is broken
> --
>
>
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693026#comment-17693026
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/24/23 6:30 PM:
--
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it?
I finally recollected how to create module in the intelliJ and now can make the
test work on the Cassandra-4.1 and can look into the trunk build failure for
the examples/ssl-factory also if needed. Modules have always given me hard time
in IntelliJ :( (may be because I don't use them much manually in other areas -
maven/gradle modules setup things automatically). May be we can add
generate-idea-files for the examples/ssl-factory module also and run it to make
it easier for people.
was (Author: maulin.vasavada):
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it?
I finally recollected how to create module in the intelliJ and now can make the
test work on the Cassandra-4.1 and can look into the trunk build failure for
the examples/ssl-factory also if needed. Modules have always given me hard time
in IntelliJ :( (may be because I don't use them much in other areas). May be we
can add generate-idea-files for the examples/ssl-factory module also and run it
to make it easier for people.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693026#comment-17693026
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/24/23 7:35 AM:
--
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it?
I finally recollected how to create module in the intelliJ and now can make the
test work on the Cassandra-4.1 and can look into the trunk build failure for
the examples/ssl-factory also if needed. Modules have always given me hard time
in IntelliJ :( (may be because I don't use them much in other areas). May be we
can add generate-idea-files for the examples/ssl-factory module also and run it
to make it easier for people.
was (Author: maulin.vasavada):
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it?
I finally recollected how to create module in the intelliJ and now can make the
test work on the Cassandra-4.1 and can look into the trunk build failure for
the examples/ssl-factory also if needed. Modules have always given me hard time
in IntelliJ :( (may be because I don't use them much in other areas).
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693026#comment-17693026
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/24/23 7:27 AM:
--
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it?
I finally recollected how to create module in the intelliJ and now can make the
test work on the Cassandra-4.1 and can look into the trunk build failure for
the examples/ssl-factory also if needed. Modules have always given me hard time
in IntelliJ :( (may be because I don't use them much in other areas).
was (Author: maulin.vasavada):
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it? Thanks
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693026#comment-17693026
]
Maulin Vasavada commented on CASSANDRA-18270:
-
On the trunk I see that the CASSANDRA-17513 changes modified the main source
but doesn't seem to have updated the examples/ssl-factory so I can't compile
the examples/ssl-factory at all. However, if someone can verify the same it
would be great. cc: [~Jyothsnakonisa] [~djoshi] Do you have some bandwidth to
take a look at it? Thanks
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17692917#comment-17692917
]
Maulin Vasavada commented on CASSANDRA-18270:
-
`Update` I built it locally but so far no luck in running `ant build`
successfully on the trunk :( The 4.1 branch works. Still looking into it.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17692917#comment-17692917
]
Maulin Vasavada edited comment on CASSANDRA-18270 at 2/23/23 9:20 PM:
--
`Update` I built it locally but so far no luck in running `ant build`
successfully for the examples/ssl-factory on the trunk :( The 4.1 branch works.
Still looking into it.
was (Author: maulin.vasavada):
`Update` I built it locally but so far no luck in running `ant build`
successfully on the trunk :( The 4.1 branch works. Still looking into it.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
> Fix For: 4.1.x, 4.x
>
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-18270:
---
Assignee: Maulin Vasavada
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Assignee: Maulin Vasavada
>Priority: Normal
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18270) ssl-factory demo in examples is broken
[
https://issues.apache.org/jira/browse/CASSANDRA-18270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17690527#comment-17690527
]
Maulin Vasavada commented on CASSANDRA-18270:
-
[~smiklosovic] Sure, I should be able to take a look at this in the next week.
> ssl-factory demo in examples is broken
> --
>
> Key: CASSANDRA-18270
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18270
> Project: Cassandra
> Issue Type: Bug
>Reporter: Stefan Miklosovic
>Priority: Normal
>
> this fails, it is not happening in cassandra-4.1
> {code}
> cd examples/ssl-factory
> ant build && ant test
> {code}
> My suspicion is that SSL factory related stuff was recently changed, in
> trunk, by (1) and this broke related ssl test.
> [~maulin.vasavada] do you have some time to look into that as you are the
> author of the tests? I think I fixed the most of it here (2) but one test is
> still failing and I can not wrap my head around that one. It gives:
> {code}
> [junit] Testcase:
> buildKeyManagerFactoryHappyPathForUnencryptedKey(org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest):
> Caused an ERROR
> [junit] Failed to build key manager store for secure connections
> [junit] javax.net.ssl.SSLException: Failed to build key manager store for
> secure connections
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:267)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:229)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactory.buildKeyManagerFactory(KubernetesSecretsPEMSslContextFactory.java:169)
> [junit] at
> org.apache.cassandra.security.KubernetesSecretsPEMSslContextFactoryTest.buildKeyManagerFactoryHappyPathForUnencryptedKey(KubernetesSecretsPEMSslContextFactoryTest.java:244)
> [junit] Caused by: java.io.IOException: overrun, bytes = 1195
> [junit] at
> javax.crypto.EncryptedPrivateKeyInfo.(EncryptedPrivateKeyInfo.java:95)
> [junit] at
> org.apache.cassandra.security.PEMReader.extractPrivateKey(PEMReader.java:108)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyStore(PEMBasedSslContextFactory.java:319)
> [junit] at
> org.apache.cassandra.security.PEMBasedSslContextFactory.buildKeyManagerFactory(PEMBasedSslContextFactory.java:251)
> {code}
> (1)
> https://github.com/apache/cassandra/commit/ed3901823a5fe9f8838d8b592a1b7703b12e810b
> (2)
> https://github.com/instaclustr/cassandra/tree/CASSANDRA-18264-trunk-followup
> cc [~Jyothsnakonisa]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525961#comment-17525961 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/21/22 8:17 PM: -- Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some more 'security' experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? -Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured?- I realized that they can configure the same path for the 'outbound keystore' in that case. was (Author: maulin.vasavada): Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more 'security' experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? -Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured?- I realized that they can configure the same path for the 'outbound keystore' in that case. > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1.5h > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525974#comment-17525974
]
Maulin Vasavada edited comment on CASSANDRA-17513 at 4/21/22 6:50 PM:
--
{code:java}
I am open to considering implementing this idea if we don't force operators to
explicitly a single store file i.e. maintain backward compatibility with what
we have. However, it feels like this should be out of scope here and we can
create a separate ticket to address it across both native and internode
configurations {code}
On the above quote, if I understand you correctly- you are suggesting that
somebody can work on a separate ticket to support having client/server keys in
the same keystore (in case anybody needs it)?
If my understanding is correct- then yes I agree that it should be a separate
concern out of the scope of this ticket.
was (Author: maulin.vasavada):
{code:java}
I am open to considering implementing this idea if we don't force operators to
explicitly a single store file i.e. maintain backward compatibility with what
we have. However, it feels like this should be out of scope here and we can
create a separate ticket to address it across both native and internode
configurations {code}
On the above quote, if I understand you correctly- you are suggesting that
somebody can work on a separate ticket to support having client/server keys in
the same keystore (in case anybody needs it)?
If my understand is correct- then yes I agree that it should be a separate
concern out of the scope of this ticket.
> Adding support for TLS client authentication for internode communication
>
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[
https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525974#comment-17525974
]
Maulin Vasavada commented on CASSANDRA-17513:
-
{code:java}
I am open to considering implementing this idea if we don't force operators to
explicitly a single store file i.e. maintain backward compatibility with what
we have. However, it feels like this should be out of scope here and we can
create a separate ticket to address it across both native and internode
configurations {code}
On the above quote, if I understand you correctly- you are suggesting that
somebody can work on a separate ticket to support having client/server keys in
the same keystore (in case anybody needs it)?
If my understand is correct- then yes I agree that it should be a separate
concern out of the scope of this ticket.
> Adding support for TLS client authentication for internode communication
>
>
> Key: CASSANDRA-17513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17513
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Same keystore is being set for both Inbound and outbound connections but we
> should use a keystore with server certificate for Inbound connections and a
> keystore with client certificates for outbound connections. So we should add
> a new property in Cassandra.yaml to pass outbound keystore and use it in
> SSLContextFactory for creating outbound SSL context.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525969#comment-17525969 ] Maulin Vasavada commented on CASSANDRA-17513: - +1 from my side. Thanks for your patience. > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525961#comment-17525961 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/21/22 6:38 PM: -- Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more 'security' experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? -Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured?- I realized that they can configure the same path for the 'outbound keystore' in that case. was (Author: maulin.vasavada): Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more 'security' experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured? > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525961#comment-17525961 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/21/22 6:34 PM: -- Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more 'security' experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured? was (Author: maulin.vasavada): Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more security experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured? > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Adding support for TLS client authentication for internode communication
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525961#comment-17525961 ] Maulin Vasavada commented on CASSANDRA-17513: - Thank you [~djoshi] for considering the suggestion for the ticket title. I've thought about it (little experimented also) and talked to some of the more security experts and I agree with the approach to have a separate keystore for client vs server certs for internode connections in case we need to have client auth enabled. While Java keystores provide ability to store multiple keys in it, for variety of reasons (some of which you already mentioned in your lastest comment) it makes sense to keep client vs server keys separate. Given that we would need a different keystore for client TLS auth for the internode connection, what if somebody wants to use the same certs for client as well as server auth? Would they be required to copy it to a separate keystore OR the code changes would have a fallback when the 'outbound keystore' (how current PR refers to) is not configured? > Adding support for TLS client authentication for internode communication > > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.7#820007) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523805#comment-17523805 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/19/22 12:09 AM: --- [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. -However, so far from Java code standpoint I am not able to locate the place where it checks the OID/extendedKeyUsage field for client/server cert reading from a keystore.- I think I found [the code|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L566] in OpenJDK 8 that checks for the extendedKeyUsage on a certificate while choosing from the keystore. So according to this it should be able to differentiate between client/server certs from the same keystore. was (Author: maulin.vasavada): [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. -However, so far from Java code standpoint I am not able to locate the place where it checks the OID/extendedKeyUsage field for client/server cert reading from a keystore.- I think I found [the code|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L566] in OpenJDK 8 that checks for the extendedKeyUsage on a certificate while choosing from the keystore. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523805#comment-17523805 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/19/22 12:08 AM: --- [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. -However, so far from Java code standpoint I am not able to locate the place where it checks the OID/extendedKeyUsage field for client/server cert reading from a keystore.- I think I found [the code|https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java#L566] in OpenJDK 8 that checks for the extendedKeyUsage on a certificate while choosing from the keystore. was (Author: maulin.vasavada): [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. However, so far from Java code standpoint I am not able to locate the place where it checks the OID/extendedKeyUsage field for client/server cert reading from a keystore. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523805#comment-17523805 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/18/22 11:49 PM: --- [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. However, so far from Java code standpoint I am not able to locate the place where it checks the OID/extendedKeyUsage field for client/server cert reading from a keystore. was (Author: maulin.vasavada): [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523805#comment-17523805 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/18/22 11:47 PM: --- [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? I think writing up [a sample https server/client|https://bugs.openjdk.java.net/browse/JDK-8262186] locally could help test/verify that. was (Author: maulin.vasavada): [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523805#comment-17523805 ] Maulin Vasavada commented on CASSANDRA-17513: - [~Jyothsnakonisa] and [~djoshi] - would it be possible to put both private keys - server and client in the same keystore? I've never tried it so not sure but would Java be able to use correct certificate based on whether it requires Server certificate or a Client certificate? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522942#comment-17522942 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 8:08 PM: -- Does it make sense to change the title of this ticket/PR to reflect it clearly - "Adding support for TLS client authentication for internode communication"? was (Author: maulin.vasavada): Does it make sense to change the title of this ticket to reflect it clearly - "Adding support for TLS client authentication for internode communication"? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522942#comment-17522942 ] Maulin Vasavada commented on CASSANDRA-17513: - Does it make sense to change the title of this ticket to reflect it clearly - "Adding support for TLS client authentication for internode communication"? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522900#comment-17522900 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 5:07 PM: -- Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. I'll also take a look at the code changes in the PR and provide any comments I may have. Thanks [~Jyothsnakonisa] for working on the changes. was (Author: maulin.vasavada): Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522900#comment-17522900 ] Maulin Vasavada commented on CASSANDRA-17513: - Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522894#comment-17522894 ] Maulin Vasavada commented on CASSANDRA-17513: - Thanks [~djoshi] that clarifies it for me. Also I agree with your operational overhead comment. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 3:04 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. We also have to be cognizant of an operational overhead managing so many keypairs. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:35 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've not seen such a setup. It makes total sense to me to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds odd to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds suspicious to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:33 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. However it sounds suspicious to say I want to use Identity-A when I am acting as a server to a given peer and use Identity-B when I am acting as a client to the same peer. The way I think is - A node has an identity that it uses to-be trusted- be it a client or server mode with the same peer. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 1:30 AM: -- Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? If you are thinking that you want two different keystores for each server node - 1) for sending a server cert and 2) for sending the client cert, I would +1 Brandon's question - What would be your motivation to do that? In my experience I've never seen such a setup. It makes total sense to say - Hey my server node has Identity-A and that is what I use to send to my client to trust me as well as when I am the client, I would use that to-be trusted by the receiver. was (Author: maulin.vasavada): Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522461#comment-17522461 ] Maulin Vasavada commented on CASSANDRA-17513: - Hi [~Jyothsnakonisa] Based on what you are saying, you seem to clearly understand client/server encryption options. However I fail to understand your challenge. Do you want to be able to configure different keystores for each server node? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/14/22 12:10 AM: --- [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, *Server side* # Need to have a 'truststore' having the CAs who signed the client-certificates # To be able to send server cert to client, you need 'keystore' *Client side* # Need to have a 'truststore' having CAs who signed the server certificate # You need to configure keystore as supported by your client library so that when the server asks for a client-certificate it can fetch it from the client side keystore. Please let me know if this helps. was (Author: maulin.vasavada): [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, you need 'truststore' (on the server side) and to be able to send server cert to client, you need 'keystore' (on the server side). Of course on the client side, you need to configure keystore as supported by your client library so that when the server asks for a client-certificate it can fetch it from the client side keystore. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/14/22 12:03 AM: --- [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, you need 'truststore' (on the server side) and to be able to send server cert to client, you need 'keystore' (on the server side). Of course on the client side, you need to configure keystore as supported by your client library so that when the server asks for a client-certificate it can fetch it from the client side keystore. Please let me know if this helps. was (Author: maulin.vasavada): [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, you need 'truststore' and to be able to send server cert to client, you need 'keystore'. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/13/22 5:36 AM: -- [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, you need 'truststore' and to be able to send server cert to client, you need 'keystore'. Please let me know if this helps. was (Author: maulin.vasavada): [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada commented on CASSANDRA-17513: - [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516980#comment-17516980 ] Maulin Vasavada commented on CASSANDRA-16456: - [~bhouser] I have put couple of comments on the PR. Please take a look when you get a chance. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 20m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508583#comment-17508583
]
Maulin Vasavada edited comment on CASSANDRA-16895 at 3/18/22, 5:12 PM:
---
I guess it could be because prior TLS versions ({-}before{-} prior to TLSv1.2)
are disabled in JDK 17 and the python client in python 3.8 might be defaulting
to those. Not sure though, trying to look into it more.
was (Author: maulin.vasavada):
I guess it could be because prior TLS versions (before TLSv1.2) are disabled in
JDK 17 and the python client in python 3.8 might be defaulting to those. Not
sure though, trying to look into it more.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16895) Support Java 17
[
https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17508959#comment-17508959
]
Maulin Vasavada edited comment on CASSANDRA-16895 at 3/18/22, 5:11 PM:
---
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
Basically, if my understanding is right, the test is running cqlsh to describe
namespace and uses ssl options specifying the certificate so I assume it
connects to the node started by the test over ssl.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers',
{'127.0.0.1:9042': ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1
alert internal error (_ssl.c:2635)')}
)` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
was (Author: maulin.vasavada):
Yes I am with you guys [~brandon.williams] and [~e.dimitrova] . I meant
versions prior to TLSv1.2 are disabled in Jdk 17. Hence my initial guess was -
what TLS protocol it uses when we trigger the run_cqlsh() from the python test.
If that was passing/using older version of the TLS than v1.2 it could fail.
Basically, if my understanding is right, the test is running cqlsh to describe
namespace and uses ssl options specifying the certificate so I assume it
connects to the node started by the test via ssl.
However based on Ekaterina's findings it seems the Netty upgrade may be the
cause of the underlying failure. My initial research was just based on the test
run logs I could see `assert "Connection e...c:2635)')})\n" == '' - Connection
error: ('Unable to connect to any servers', {'127.0.0.1:9042':
ConnectionShutdown('[SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal
error (_ssl.c:2635)')})` .
All-in-all, I believe we don't need to further suspect TLS at this point?
Please let me know otherwise, I can debug further.
> Support Java 17
> ---
>
> Key: CASSANDRA-16895
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16895
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> This ticket is intended to group all issues found to support Java 17 in the
> future.
> Upgrade steps:
> * [Dependencies
> |https://mvnrepository.com/artifact/org.apache.cassandra/cassandra-all/4.0.1]to
> be updated (not all but at least those that require an update in order to
> work with Java 17)
> * More encapsulated JDK internal APIs. Some of the issues might be solved
> with the dependencies updates
> * Currently trunk compiles if we remove the Nashorn dependency (ant script
> tag, used for the test environment; UDFs) . The oracle recommendation to use
> Nashorn-core won't work for the project as it is under GPL 2.0. Most probably
> we will opt in for graal-sdk licensed under UPL
> * All tests to be cleaned
> * CI environment to be setup
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
