[
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421260#comment-17421260
]
Stefan Miklosovic commented on CASSANDRA-16666:
-----------------------------------------------
Hi [~maulin.vasavada], can I ask you to prepare your branch in such a fashion
that all these commits are on top of the current trunk? If you look into CEP-9
branch commit history, what I see is that all these commits of yours are
somehow intertwined will all other stuff. I am not sure how to merge this in
this state to be honest. Maybe I am just not getting something but I would
expect that the workflow you had is like continuously rebasing your branch
against trunk and applying more stuff on top of that as we go, no merging it. I
attached the screenshot to better understand what I mean. (if you scroll deep
enough, there are other places, not fitting into the screenshot, where more of
your commits are located too). Hence I would ideally like to see all your
changes on top of the current trunk, 50 commits or what have you, or prepare
one commit only by squashing all your changes into one single commit and push
that one (ideally to a separate branch so we have the original one still
available). !Screenshot from 2021-09-28 10-56-24.png!
> Make SSLContext creation pluggable/extensible
> ---------------------------------------------
>
> Key: CASSANDRA-16666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16666
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
> Reporter: Maulin Vasavada
> Assignee: Maulin Vasavada
> Priority: Normal
> Fix For: 4.x
>
> Attachments: Screenshot from 2021-09-28 10-56-24.png
>
>
> Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is
> a final class with static methods and not overridable. The SSLFactory loads
> the keys and certs from the file based artifacts for the same. While this
> works for many, in the industry where security is stricter and contextual,
> this approach falls short. Many big organizations need flexibility to load
> the SSL artifacts from a custom resource (like custom Key Management
> Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider
> architecture allows us flexibility to build our custom mechanisms to validate
> and process security artifacts, many times all we need is to build upon
> Java's existing extensibility that Trust/Key Manager interfaces provide to
> load keystores from various resources in the absence of any customized
> requirements on the Keys/Certificate formats.
> My proposal here is to make the SSLContext creation pluggable/extensible and
> have the current SSLFactory.java implement an extensible interface.
> I contributed a similar change that is live now in Apache Kafka (2.6.0) -
> https://issues.apache.org/jira/browse/KAFKA-8890
> I can spare some time writing the pluggable interface and run by the required
> reviewers.
>
> Created [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>
>
> cc: [~dcapwell] [~djoshi]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
