I have gone through the CEP and I have no concerns on voting on it. In my case a PR helps me pin down and understand better what the CEP will indeed look like, I like that a lot. So thx Maulin for the detailed PR with the luxury of all tests and all bells and whistles!. If it were a CEP of my own though my PR would be with pseudo-code or similar, for illustration and brainstorming purposes only, just to give enough context for the voting. That way if my CEP gets declined I haven't wasted so much effort.
My 2cts. On 13/7/21 0:25, Ekaterina Dimitrova wrote: > Hi everyone, > > Reading the thread I feel we are all more or less on the same page. > > My personal line of thinking: > 1) I really like Benedict’s idea of some kind of cheat sheet > 2) I think some kind of PoC PR, when/if needed, sounds reasonable. Probably > It can help in some cases the author to reconsider or even explain better > some suggestions/decisions. In that sense, I think I agree with Maulin that > probably Jira ticket after voted CEP is a good idea. I think that when we > put PR in a Jira ticket (at least I as a creature of habit) we start > thinking of more diligent reviews and might forget it is still unapproved > CEP and get into details that doesn’t really matter at this point in time. > But that might be only me. :-) > > Best regards, > Ekaterina > > On Mon, 12 Jul 2021 at 15:47, Maulin Vasavada <maulin.vasav...@gmail.com> > wrote: > >> Thank you Benjamin. Sounds good to me. >> >> I feel if we leave full control of creating SSL's context (including >> ciphers, accepted protocols values etc) to the interface it would work. >> There are some other requirements people run into like customizing X 509 >> cert validations (SPIFFE >> <https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md>), >> using >> different SSL Providers (like Bouncy Castle, Boring SSL etc) altogether >> which in my opinion can be better served with exploration of JSSE Providers >> (java's security.provider configuration) instead of trying to customize >> just the SSL Context. However, leaving full control with the SSL context >> factory interface may mean supporting 'Map' as modelling the configuration >> vs keeping 'CommonEncryptionOption' but that would again go into more >> technical discussion so we can keep it separate. >> >> Thanks >> Maulin >> >> On Mon, Jul 12, 2021 at 3:27 AM Benjamin Lerer <b.le...@gmail.com> wrote: >> >>>> In the context of your latest answers on JIRA - your interface makes >>> sense >>>> to me, I just want to be sure that we will not forget to add anything >>> which >>>> would a respective implementator need in the future and could not use >>>> because it is just not exposed. >>> >>> I do not believe that we can build the perfect interface. Sadely, it is >>> impossible to know what future implementations will require. Outside of >>> the obvious issues that we can think of right now, I believe that we >> will >>> just have to find some solutions at the time where the problems arise. >>> >>> The thread is right now going into technical areas that could be >> discussed >>> on the PR later on. It might be a sign that there are no high level >>> concerns with the CEP and that we should simply trigger the vote. >>> If nobody disagrees, I will start the vote tomorrow. >>> >>> >>> >>> Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever <m...@apache.org> a écrit >> : >>>> Thanks for bringing this back to the ML Maulin. >>>> Very much appreciated. >>>> >>>> On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada < >> maulin.vasav...@gmail.com >>>> wrote: >>>> >>>>> Thanks Stefan for the pointer for the 'examples' directory. Will >> invest >>>>> time in coming up with a reference custom implementation. >>>>> >>>>> For your other comments around common encryption options, I agree >> with >>>> you >>>>> on a challenge in order to prevent secure information getting leaked >> in >>>>> logs. Let me create a separate branch and show how interface will >>> change >>>>> with keeping Common Encryption options + map instead of just the map. >>>>> >>>>> Thanks >>>>> Maulin >>>>> >>>>> On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada < >>>> maulin.vasav...@gmail.com> >>>>> wrote: >>>>> >>>>>> Stefan Miklosovic >>>>>> <https://cwiki.apache.org/confluence/display/~stefan.miklosovic> >>>>>> >>>>>> Hi MAULIN VASAVADA >>>>>> <https://cwiki.apache.org/confluence/display/~maulin.vasavada>, >> few >>>> more >>>>>> observations. I see that you have commented again on JIRA and I am >>>>> starting >>>>>> to be confused where to comment in relation to recent thread we had >>>> about >>>>>> this so I am letting you know that I am ultimately using this >>>>> communication >>>>>> channel for discussion. >>>>>> >>>>>> In the context of your latest answers on JIRA - your interface >> makes >>>>> sense >>>>>> to me, I just want to be sure that we will not forget to add >> anything >>>>> which >>>>>> would a respective implementator need in the future and could not >> use >>>>>> because it is just not exposed. I am not completely sure how to >> solve >>>>> this >>>>>> but I think that we just have to stick to our gut feeling that the >>>>> solution >>>>>> proposed will cover the most scenarios. >>>>>> >>>>>> If we do not feel safe, my idea was to show yet another >>> implementation >>>>>> where the possibility we would left a user behind is minimised. >>>>> Otherwise, >>>>>> without breaking older implementations used in future releases, we >>>> could >>>>>> only introduce methods which would have default implementations. >>>>>> >>>>>> I prefer to have a map instead of common encryption options. On the >>>> other >>>>>> hand, I can imagine that the custom implementation would try to >>> bypass >>>>> some >>>>>> credentials into it (for example how to connect to a respective >>> source >>>> of >>>>>> these keystores / truststores) and if we ever decided to have some >>> kind >>>>> of >>>>>> a tooling around this, e.g. in nodetool, to get a status of "how >> ssl >>> is >>>>>> configured", we might unintentionally leak security sensitive >>>> information >>>>>> (credentials) by displaying them in plaintext in such tooling. We >> are >>>>> using >>>>>> JMX for this (I might expand on this if you are not familiar with >>> that >>>>>> mechanism of getting runtime info from Cassandra via JMX). Hence >> what >>>> we >>>>>> might do is to actually not expose that map at all. We are not >>> exposing >>>>>> this kind of information yet in runtime and I do not think we >>> actually >>>>> have >>>>>> a need for that I just find it important to say. >>>>>> >>>>>> I like the fact that configuration parameters for an implementation >>> are >>>>>> coupled with that factory configuration and it is just a basic map. >>>> Since >>>>>> implementations are getting their EncryptionOptions + map of >>> customs, I >>>>>> prefer this instead of putting there whole map of parameters >> because >>>> then >>>>>> you are just again "parsing it" from map in respective >> constructors. >>>>> There >>>>>> is nothing wrong with how this is done in your original PR, I would >>>> say. >>>>>> The very same pattern of "maps" may be found across the code base, >>> e.g. >>>>>> auditing and similar. >>>>>> >>>>>> On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada < >>>>> maulin.vasav...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Stefan Miklosovic >>>>>>> <https://cwiki.apache.org/confluence/display/~stefan.miklosovic> >>>>>>> >>>>>>> I ve taken a look too. Added some comments to PR. >>>>>>> >>>>>>> It would be awesome if we see some 3rd party implementation of >> this >>> in >>>>>>> action so we know it indeed works as intended. It is strange to >> just >>>>> code >>>>>>> up an interface by default logic for which it works but there isnt >>> any >>>>>>> (public) example how to do yet another impl. >>>>>>> >>>>>>> there is a directory called "examples" in the root of the >>> repository. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 9, 2021 at 2:58 PM Maulin Vasavada < >>>>> maulin.vasav...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> [image: maulin.vasavada]Maulin Vasavada >>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=maulin.vasavada >>>>> added >>>>>>>> a comment - Yesterday - edited >>>>>>>> >>>>>>>> On second thoughts Stefan Miklosovic >>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan.miklosovic >>>>>> , >>>>>>>> I feel if we examine the interface properly and make sure of the >>>>> contract >>>>>>>> and dependencies - input arguments to the methods and >> construction >>> of >>>>> the >>>>>>>> implementation (for which I agree there is no good way given an >>>>> interface) >>>>>>>> object AND the return types/exceptions, it could be evaluated >>> without >>>>>>>> sample of a specific/custom implementation. The premise is very >>>> simple >>>>> - >>>>>>>> Allow SSLContext (in this case JSSE's and Netty's) creation to be >>>>>>>> pluggable. Once we do that the specific implementation should not >>>>> matter. >>>>>>>> However the Cassandra's current integration point with that >>> pluggable >>>>>>>> interface does matter and need to make sure we are not violating >>>>> existing >>>>>>>> behavior - example - Caching of the Netty's ssl contexts, >>> invocation >>>> of >>>>>>>> context for Inbound/Outbound and Client/Native connections, >> threads >>>>> running >>>>>>>> for enabling hot reloading periodically etc. I know its a long >>> answer >>>>> to >>>>>>>> your question but I have done very similar work for Apache Kafka >> ( >>>>>>>> reference >>>>>>>> < >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=128650952 >>>>>> ) >>>>>>>> and feel confident that it will work for custom implementations >>> (like >>>>> ours >>>>>>>> is running in production for about 2 years now, albeit private >>>>>>>> implementation). I've consulted many security experts internally >>> and >>>>>>>> externally to validate that - making SSLContext >>>> customizable/pluggable >>>>> is >>>>>>>> the best way to support various specific needs of bigger >>> eco-systems. >>>>>>>> >>>>>>>> >>>>>>>> In fact based on my evaluation of the design - I do have two sub >>>>> options >>>>>>>> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations >>>>> that >>>>>>>> I seek input from the community on - about consolidating all the >>>>> encryption >>>>>>>> options as a open ended Map argument coming to the interface's >>>>>>>> implementation vs having a notion of CommonEncryptionOptions to >>> keep >>>>> some >>>>>>>> of the existing implementation as-is. >>>>>>>> >>>>>>>> On Fri, Jul 9, 2021 at 2:58 PM Maulin Vasavada < >>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi Sumanth Pasupuleti >>>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sumanth.pasupuleti >>>>>>>>> and Stefan Miklosovic >>>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan.miklosovic >>>>> thanks >>>>>>>>> for comments. Sorry I missed them before since I was just >> checking >>>>> DISCUSS >>>>>>>>> thread on the CEP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sumanth, I totally get what you are saying. However I feel the >>> same >>>>> way >>>>>>>>> as you do that this is just SSLContext pluggability change and >>> your >>>>>>>>> suggestion should be a follow-up on the CEP-9 change. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Stefan, your point is valid but I can only verify a custom >>>>>>>>> implementation with our company's internal requirements. However >>> it >>>>> may be >>>>>>>>> worth to provide a sample integration with HashiCorp Vault for >>>>> example to >>>>>>>>> fetch keys/certs and have a PoC. Not sure where that sample can >> be >>>>> hosted >>>>>>>>> though. >>>>>>>>> >>>>>>>>> Based on the latest discussion around improving CEP process, we >>> may >>>>>>>>> need to copy paste this discussion to DISCUSS thread also. Can >> you >>>>> please >>>>>>>>> post/copy your comments and I'd copy mine there? >>>>>>>>> >>>>>>>>> On Fri, Jul 9, 2021 at 2:58 PM Maulin Vasavada < >>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> [image: stefan.miklosovic]Stefan Miklosovic >>>>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan.miklosovic >>>>> added >>>>>>>>>> a comment - 01/Jul/21 19:20 >>>>>>>>>> >>>>>>>>>> I ve taken a look too. Added some comments to PR. >>>>>>>>>> >>>>>>>>>> It would be awesome if we see some 3rd party implementation of >>> this >>>>> in >>>>>>>>>> action so we know it indeed works as intended. It is strange to >>>> just >>>>> code >>>>>>>>>> up an interface by default logic for which it works but there >>> isnt >>>>> any >>>>>>>>>> (public) example how to do yet another impl. >>>>>>>>>> >>>>>>>>>> On Fri, Jul 9, 2021 at 2:57 PM Maulin Vasavada < >>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Sumanth Pasupuleti >>>>>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sumanth.pasupuleti >>>>> added >>>>>>>>>>> a comment - 07/Jun/21 15:13 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Maulin Vasavada >>>>>>>>>>> < >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=maulin.vasavada >>>>> left >>>>>>>>>>> a couple of review comments, but lgtm overall. >>>>>>>>>>> >>>>>>>>>>> One of the things I was hoping we can also achieve is to be >> able >>>> to >>>>>>>>>>> provide mechanics to transparently transition from using one >>>>> SSLFactory >>>>>>>>>>> implementation to another, and using those mechanics, one >> could >>> do >>>>> the >>>>>>>>>>> following on their cluster for moving from say Implementation1 >>> to >>>>>>>>>>> Implementation2 >>>>>>>>>>> Stage #1: Current state of being only Implementation1 aware. >> Use >>>>>>>>>>> keystore and trustmanager of implementation1 >>>>>>>>>>> Stage #2: Start trusting both implementation1 and >>> implementation2. >>>>>>>>>>> Use keystore of implementation1, but use trustmanager of both >>>>>>>>>>> implementation1 and implementation2 (using >>>>> MultiTrustManagerFactory) (and >>>>>>>>>>> perform a rolling restart of the cluster) >>>>>>>>>>> Stage #3: Start using implementation2 for keystore, and >> perform >>> a >>>>>>>>>>> rolling restart of the cluster >>>>>>>>>>> Stage #4: At this point, all nodes of the cluster are using >>>>>>>>>>> implementation2 for keystore, but trust both implementation1 >> and >>>>>>>>>>> implementation2, and we can now remove implementation1 from >>>>> trustmanagers, >>>>>>>>>>> and do a rolling restart. >>>>>>>>>>> >>>>>>>>>>> Since this ticket is about making SSLContext pluggable, I >>> believe >>>>>>>>>>> this is out of scope; cut a separate ticket CASSANDRA-16719 >>>>>>>>>>> <https://issues.apache.org/jira/browse/CASSANDRA-16719> to >>> track >>>>>>>>>>> that work (I did an internal 3.0 patch for this transition >> work, >>>>> and I can >>>>>>>>>>> try porting it to 4.x once this ticket is committed) >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 9, 2021 at 2:56 PM Maulin Vasavada < >>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all >>>>>>>>>>>> >>>>>>>>>>>> I wanted to consolidate a couple of comments that started in >>>>>>>>>>>> JIRA/Wiki here to keep it in one place. I'll post different >>> posts >>>>> as >>>>>>>>>>>> replies for each comment. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Maulin >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 29, 2021 at 1:07 PM Maulin Vasavada < >>>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> ^^^ bumping up ^^^ this thread since people might have more >>> time >>>>>>>>>>>>> reviewing post 4.0 work. Specifically for this >>>>>>>>>>>>> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations >>>>>>>>>>>>> section in the CEP, I have coded for one option (here >>>>>>>>>>>>> < >> https://github.com/maulin-vasavada/cassandra/commit/256ad30ecedbc50d66d8a039f8ca9e47074737ce >>>>>> ) >>>>>>>>>>>>> and now will do for another option very soon. >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada < >>>>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you Dinesh and everybody. Will keep calm and wait for >>> the >>>>>>>>>>>>>> feedback. Meanwhile I am experimenting with various >>>>> implementation options >>>>>>>>>>>>>> for what I put as "will seek community's input >>>>>>>>>>>>>> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations >>>>>> " >>>>>>>>>>>>>> on the CEP document and learning little bit more about the >>>>> CircleCI. >>>>>>>>>>>>>> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi >>>>>>>>>>>>>> <djos...@icloud.com.invalid> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Maulin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for the CEP & Patch. I’ve been following along >>>> albeit >>>>>>>>>>>>>>> silently. Will take a look. It’s just that we’re currently >>>> busy >>>>> so bear >>>>>>>>>>>>>>> with us. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Dinesh >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jun 2, 2021, at 3:28 PM, Maulin Vasavada < >>>>>>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>>>>>> Hi all >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ^^^ bump ^^^ I've raised the PR and am waiting for the >>>> review. >>>>>>>>>>>>>>> Once I see >>>>>>>>>>>>>>>> that the suggested changes are directionally right I'll >>>> start >>>>> a >>>>>>>>>>>>>>> VOTE thread >>>>>>>>>>>>>>>> on the CEP (unless I am recommended to follow another >>>>> process). >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Maulin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, May 27, 2021 at 1:29 PM Maulin Vasavada < >>>>>>>>>>>>>>> maulin.vasav...@gmail.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> HI all >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've raised the PR with the changes. Specifically I >> would >>>>>>>>>>>>>>> appreciate the >>>>>>>>>>>>>>>>> community's input on this section of the CEP >>>>>>>>>>>>>>>>> < >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Once we get some consensus on the PR (except minor code >>>>>>>>>>>>>>> improvement >>>>>>>>>>>>>>>>> suggestions) I'll start a VOTE thread for the CEP. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I thank all the reviewers of the CEP and the PR in >>> advance >>>>> and >>>>>>>>>>>>>>> am >>>>>>>>>>>>>>>>> completely excited to contribute to Apache Cassandra. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> Maulin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, May 27, 2021 at 11:04 AM Maulin Vasavada < >>>>>>>>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sounds good Brandon. I'll raise the PR in a couple of >>>> hours >>>>>>>>>>>>>>> from now. >>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, May 27, 2021 at 10:14 AM Brandon Williams < >>>>>>>>>>>>>>> dri...@gmail.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> You can raise a PR in any state, but review will be a >>>>>>>>>>>>>>> different >>>>>>>>>>>>>>>>>>> matter. I would go ahead and raise it and the >> testing >>>> can >>>>>>>>>>>>>>> be sorted >>>>>>>>>>>>>>>>>>> out from there. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, May 27, 2021 at 12:12 PM Maulin Vasavada >>>>>>>>>>>>>>>>>>> <maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> Hi all >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think I am close to raising a PR now but my >> CircleCI >>>> job >>>>>>>>>>>>>>>>>>>> < >>>>> https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra >>>>>>>>>>>>>>>>>>>> doesn't make progress beyond key tasks success like >>> unit >>>>>>>>>>>>>>> tests, dtests, >>>>>>>>>>>>>>>>>>>> cqlshlibtests. Any recommendation on if we need to >> see >>>> the >>>>>>>>>>>>>>> whole >>>>>>>>>>>>>>>>>>> CircleCI >>>>>>>>>>>>>>>>>>>> job green before raising the PR? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> Maulin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, May 21, 2021 at 8:54 PM Maulin Vasavada < >>>>>>>>>>>>>>>>>>> maulin.vasav...@gmail.com> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I am almost done with all changes except the code >>>> snippet >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>>>> EncryptioOptions.java which determines 'enabled' >> and >>>>>>>>>>>>>>> 'optional' >>>>>>>>>>>>>>>>>>> encryption >>>>>>>>>>>>>>>>>>>>> flags. Will raise the PR soon once I see my >> CircleCI >>>>>>>>>>>>>>> getting green. >>>>>>>>>>>>>>>>>>>>> On Fri, May 21, 2021 at 9:24 AM Maulin Vasavada < >>>>>>>>>>>>>>>>>>> maulin.vasav...@gmail.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> FYI - I am working on PR. I made some changes and >>>> trying >>>>>>>>>>>>>>> to run >>>>>>>>>>>>>>>>>>> tests. >>>>>>>>>>>>>>>>>>>>>> On Tue, May 18, 2021 at 10:14 PM Maulin Vasavada < >>>>>>>>>>>>>>>>>>>>>> maulin.vasav...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks Nate for reviewing the CEP. Yes for change >>> #3 >>>> in >>>>>>>>>>>>>>> the CEP, I >>>>>>>>>>>>>>>>>>> mean >>>>>>>>>>>>>>>>>>>>>>> to have only single Default Impl and that would >> be >>> a >>>>>>>>>>>>>>> final class, >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> overridable. It will be basically an internal >>>>>>>>>>>>>>> implementation. I've >>>>>>>>>>>>>>>>>>> updated >>>>>>>>>>>>>>>>>>>>>>> the CEP to reflect this. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tue, May 18, 2021 at 7:21 PM Nate McCall < >>>>>>>>>>>>>>> zznat...@gmail.com> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> Hi Maulin, >>>>>>>>>>>>>>>>>>>>>>>> Thanks for putting this together! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Took a quick glance, and I can't think of a >>>> compelling >>>>>>>>>>>>>>> reason on >>>>>>>>>>>>>>>>>>> why >>>>>>>>>>>>>>>>>>>>>>>> SSLContext should be final and your point about >>>>>>>>>>>>>>>>>>> organization/compliance >>>>>>>>>>>>>>>>>>>>>>>> issues requiring different implementations is a >>> good >>>>>>>>>>>>>>> one. >>>>>>>>>>>>>>>>>>>>>>>> Per #3 on your proposed changes, I'm keen to >> only >>>>>>>>>>>>>>> support a single >>>>>>>>>>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>>>>>>>>>> impl in-tree. I don't think we should be in the >>>>>>>>>>>>>>> business of >>>>>>>>>>>>>>>>>>> picking >>>>>>>>>>>>>>>>>>>>>>>> implementation to support. It looks like this is >>>> your >>>>>>>>>>>>>>> intention >>>>>>>>>>>>>>>>>>> as well? >>>>>>>>>>>>>>>>>>>>>>>> Thanks again, >>>>>>>>>>>>>>>>>>>>>>>> -Nate >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 19, 2021 at 12:05 PM Maulin >> Vasavada < >>>>>>>>>>>>>>>>>>>>>>>> maulin.vasav...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi all >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Starting a discussion thread for the CIP-9 - >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> However, while writing the CIP two areas that >>> came >>>> up >>>>>>>>>>>>>>> in my mind >>>>>>>>>>>>>>>>>>>>>>>> where I >>>>>>>>>>>>>>>>>>>>>>>>> need to seek guidance apart from the other >>>> discussion >>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>> here, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 1. Whether to consider >>>>>>>>>>>>>>>>>>> SSLFactory#tlsInstanceProtocolSubstitution() >>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>> >> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169 >>>>>>>>>>>>>>>>>>>>>>>>> for pluggability (noted this on the CIP as >> well) >>>>>>>>>>>>>>>>>>>>>>>>> 2. For Test Plan, apart from Integration Test >> and >>>>>>>>>>>>>>> local system >>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>>>>>> what >>>>>>>>>>>>>>>>>>>>>>>>> would be recommended? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>> Maulin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: >>>>> dev-unsubscr...@cassandra.apache.org >>>>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>> dev-h...@cassandra.apache.org >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, e-mail: >>> dev-unsubscr...@cassandra.apache.org >>>>>>>>>>>>>>> For additional commands, e-mail: >>>> dev-h...@cassandra.apache.org >>>>>>>>>>>>>>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
