You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Maulin Vasavada <ma...@gmail.com> on 2021/07/09 21:56:56 UTC
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
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 <ma...@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 <ma...@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 <dj...@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 <ma...@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.vasavada@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.vasavada@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 <dr...@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
>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>> >>>>
>>> >>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
Hi all
Thank you for the vote on this. Since the CEP is Accepted now, do we
discuss PR/code details on the JIRA/Github right?
Thanks
Maulin
On Wed, Jul 14, 2021 at 5:28 PM Maulin Vasavada <ma...@gmail.com>
wrote:
> Thanks Berenguer. Mainly I did detailed PR since I was not familiar with
> Cassandra codebase and wanted to make sure I figured out the magnitude of
> things lying ahead of me sooner by having tests failures etc :) Also partly
> I get chunks of time where I just focus and do things so I better utilize
> that time :)
>
> On Mon, Jul 12, 2021 at 10:33 PM Berenguer Blasi <be...@gmail.com>
> wrote:
>
>> 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.vasavada@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....@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 <mc...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
>> >>>>>>>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>> >>>>>>>>>>>>>>> driftx@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
>> >>>>>>>>>>>>>>>>>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>> >>>>>>>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>> >>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>>>>>>>>>>>>> dev-help@cassandra.apache.org
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> >>> dev-unsubscribe@cassandra.apache.org
>> >>>>>>>>>>>>>>> For additional commands, e-mail:
>> >>>> dev-help@cassandra.apache.org
>> >>>>>>>>>>>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
Thanks Berenguer. Mainly I did detailed PR since I was not familiar with
Cassandra codebase and wanted to make sure I figured out the magnitude of
things lying ahead of me sooner by having tests failures etc :) Also partly
I get chunks of time where I just focus and do things so I better utilize
that time :)
On Mon, Jul 12, 2021 at 10:33 PM Berenguer Blasi <be...@gmail.com>
wrote:
> 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.vasavada@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....@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 <mc...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
> >>>>>>>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
> >>>>>>>>>>>>>>> driftx@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
> >>>>>>>>>>>>>>>>>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
> >>>>>>>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
> >>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>> dev-help@cassandra.apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>> dev-unsubscribe@cassandra.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>> dev-help@cassandra.apache.org
> >>>>>>>>>>>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Berenguer Blasi <be...@gmail.com>.
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 <ma...@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....@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 <mc...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
>>>>>>>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>>>>>>>> driftx@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
>>>>>>>>>>>>>>>>>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>> dev-help@cassandra.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@cassandra.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@cassandra.apache.org
>>>>>>>>>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Ekaterina Dimitrova <e....@gmail.com>.
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 <ma...@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....@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 <mc...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
> > > > >>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
> > > > >>>>>>>>>> driftx@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
> > > > >>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
> > > > >>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
> > > > >>>>>>>>>> >>>> For additional commands, e-mail:
> > > > >>>>>>>>>> dev-help@cassandra.apache.org
> > > > >>>>>>>>>> >>>>
> > > > >>>>>>>>>> >>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > ---------------------------------------------------------------------
> > > > >>>>>>>>>> To unsubscribe, e-mail:
> > dev-unsubscribe@cassandra.apache.org
> > > > >>>>>>>>>> For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > >
> > >
> >
>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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....@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 <mc...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
> > > >>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
> > > >>>>>>>>>> driftx@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
> > > >>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
> > > >>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
> > > >>>>>>>>>> >>>> For additional commands, e-mail:
> > > >>>>>>>>>> dev-help@cassandra.apache.org
> > > >>>>>>>>>> >>>>
> > > >>>>>>>>>> >>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > ---------------------------------------------------------------------
> > > >>>>>>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@cassandra.apache.org
> > > >>>>>>>>>> For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > >
> >
>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Benjamin Lerer <b....@gmail.com>.
>
> 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 <mc...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
> > >>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
> > >>>>>>>>>> driftx@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
> > >>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
> > >>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
> > >>>>>>>>>> >>>> For additional commands, e-mail:
> > >>>>>>>>>> dev-help@cassandra.apache.org
> > >>>>>>>>>> >>>>
> > >>>>>>>>>> >>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > ---------------------------------------------------------------------
> > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > >>>>>>>>>> For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > >>>>>>>>>>
> > >>>>>>>>>>
> >
>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Mick Semb Wever <mc...@apache.org>.
Thanks for bringing this back to the ML Maulin.
Very much appreciated.
On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <ma...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
> >>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
> >>>>>>>>>> driftx@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
> >>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
> >>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
> >>>>>>>>>> >>>> For additional commands, e-mail:
> >>>>>>>>>> dev-help@cassandra.apache.org
> >>>>>>>>>> >>>>
> >>>>>>>>>> >>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
>>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>>> driftx@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
>>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>>>>>> >>>> For additional commands, e-mail:
>>>>>>>>>> dev-help@cassandra.apache.org
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>>
>>>>>>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
>>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>> driftx@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
>>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>>>>> >>>> For additional commands, e-mail:
>>>>>>>>> dev-help@cassandra.apache.org
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>>
>>>>>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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.vasavada@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
>>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>> driftx@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
>>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>>
>>>>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
[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 <ma...@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 <ma...@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 <ma...@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.vasavada@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.vasavada@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.vasavada@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
>>>>>> <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>> driftx@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
>>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>>
>>>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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.vasavada@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.vasavada@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 <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>> driftx@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
>>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>> >>>>
>>>>>> >>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>>
>>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
[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 <ma...@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 <ma...@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.vasavada@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.vasavada@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 <dj...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>> driftx@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
>>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>> >>>>
>>>>> >>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable
Posted by Maulin Vasavada <ma...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <dj...@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.vasavada@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.vasavada@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.vasavada@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 <driftx@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
>>>> >>>> <ma...@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.vasavada@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.vasavada@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.vasavada@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 <
>>>> zznate.m@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.vasavada@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-unsubscribe@cassandra.apache.org
>>>> >>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>> >>>>
>>>> >>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>
>>>>