Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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 
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 
> 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.vasav...@gmail.com>
>> > wrote:
>> >
>> >> Thank you Benjamin. Sounds good to me.
>> >>
>> >> I feel if we leave full control of creating SSL's context (including
>> >> ciphers, accepted protocols values etc) to the interface it would work.
>> >> There are some other requirements people run into like customizing X
>> 509
>> >> cert validations (SPIFFE
>> >> ),
>> >> 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 
>> 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  a
>> écrit
>> >> :
>>  Thanks for bringing this back to the ML Maulin.
>>  Very much appreciated.
>> 
>>  On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
>> >> maulin.vasav...@gmail.com
>>  wrote:
>> 
>> > Thanks Stefan for the pointer for the 'examples' directory. Will
>> >> invest
>> > time in coming up with a reference custom implementation.
>> >
>> > For your other comments around common encryption options, I agree
>> >> with
>>  you
>> > on a challenge in order to prevent secure information getting leaked
>> >> in
>> > logs. Let me create a separate branch and show how interface will
>> >>> change
>> > with keeping Common Encryption options + map instead of just the
>> map.
>> >
>> > Thanks
>> > Maulin
>> 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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 
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  >
> > 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
> >> ),
> >> 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 
> 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  a
> écrit
> >> :
>  Thanks for bringing this back to the ML Maulin.
>  Very much appreciated.
> 
>  On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
> >> maulin.vasav...@gmail.com
>  wrote:
> 
> > Thanks Stefan for the pointer for the 'examples' directory. Will
> >> invest
> > time in coming up with a reference custom implementation.
> >
> > For your other comments around common encryption options, I agree
> >> with
>  you
> > on a challenge in order to prevent secure information getting leaked
> >> in
> > logs. Let me create a separate branch and show how interface will
> >>> change
> > with keeping Common Encryption options + map instead of just the map.
> >
> > Thanks
> > Maulin
> >
> > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
>  maulin.vasav...@gmail.com>
> > wrote:
> >
> >> Stefan Miklosovic
> >> 
> >>
> >> Hi MAULIN VASAVADA
> >> ,
> >> few
>  more
> >> observations. I 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Berenguer Blasi]

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 
> 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
>> ),
>> 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  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  a écrit
>> :
 Thanks for bringing this back to the ML Maulin.
 Very much appreciated.

 On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
>> maulin.vasav...@gmail.com
 wrote:

> Thanks Stefan for the pointer for the 'examples' directory. Will
>> invest
> time in coming up with a reference custom implementation.
>
> For your other comments around common encryption options, I agree
>> with
 you
> on a challenge in order to prevent secure information getting leaked
>> in
> logs. Let me create a separate branch and show how interface will
>>> change
> with keeping Common Encryption options + map instead of just the map.
>
> Thanks
> Maulin
>
> On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
 maulin.vasav...@gmail.com>
> wrote:
>
>> Stefan Miklosovic
>> 
>>
>> Hi 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

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Ekaterina Dimitrova]

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 
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
> ),
> 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  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  a écrit
> :
> >
> > > Thanks for bringing this back to the ML Maulin.
> > > Very much appreciated.
> > >
> > > On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
> maulin.vasav...@gmail.com
> > >
> > > wrote:
> > >
> > > > Thanks Stefan for the pointer for the 'examples' directory. Will
> invest
> > > > time in coming up with a reference custom implementation.
> > > >
> > > > For your other comments around common encryption options, I agree
> with
> > > you
> > > > on a challenge in order to prevent secure information getting leaked
> in
> > > > logs. Let me create a separate branch and show how interface will
> > change
> > > > with keeping Common Encryption options + map instead of just the map.
> > > >
> > > > Thanks
> > > > Maulin
> > > >
> > > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > > maulin.vasav...@gmail.com>
> > > > wrote:
> > > >
> > > > > Stefan Miklosovic
> > > > > 
> > > > >
> > > > > Hi 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.
> > 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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
), 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  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  a écrit :
>
> > Thanks for bringing this back to the ML Maulin.
> > Very much appreciated.
> >
> > On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada  >
> > wrote:
> >
> > > Thanks Stefan for the pointer for the 'examples' directory. Will invest
> > > time in coming up with a reference custom implementation.
> > >
> > > For your other comments around common encryption options, I agree with
> > you
> > > on a challenge in order to prevent secure information getting leaked in
> > > logs. Let me create a separate branch and show how interface will
> change
> > > with keeping Common Encryption options + map instead of just the map.
> > >
> > > Thanks
> > > Maulin
> > >
> > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > maulin.vasav...@gmail.com>
> > > wrote:
> > >
> > > > Stefan Miklosovic
> > > > 
> > > >
> > > > Hi 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Benjamin Lerer]

>
> 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  a écrit :

> Thanks for bringing this back to the ML Maulin.
> Very much appreciated.
>
> On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada 
> wrote:
>
> > Thanks Stefan for the pointer for the 'examples' directory. Will invest
> > time in coming up with a reference custom implementation.
> >
> > For your other comments around common encryption options, I agree with
> you
> > on a challenge in order to prevent secure information getting leaked in
> > logs. Let me create a separate branch and show how interface will change
> > with keeping Common Encryption options + map instead of just the map.
> >
> > Thanks
> > Maulin
> >
> > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> > wrote:
> >
> > > Stefan Miklosovic
> > > 
> > >
> > > Hi MAULIN VASAVADA
> > > , few
> more
> > > observations. I see that you have commented again on JIRA and I am
> > starting
> > > to be confused where to comment in relation to recent thread we had
> about
> > > this so I am letting you know that I am ultimately using this
> > communication
> > > channel for discussion.
> > >
> > > In the context of your latest answers on JIRA - your interface makes
> > sense
> > > to me, I just want to be sure that we will not forget to add anything
> > which
> > > would a respective implementator need in the future and could not use
> > > because it is just not exposed. I am not completely sure how to solve
> > this
> > > but I think that we just have to stick to our gut feeling that the
> > solution
> > > proposed will cover the most scenarios.
> > >
> > > If we do not feel safe, my idea was to show yet another implementation
> > > where the possibility we would left a user behind is minimised.
> > Otherwise,
> > > without breaking older implementations used in future releases, we
> could
> > > only introduce methods which would have default implementations.
> > >
> > > I prefer to have a map instead of common encryption options. On the
> other
> > > hand, I can imagine that the custom implementation would try to bypass
> > some
> > > credentials into it (for example how to connect to a respective source
> of
> > > these keystores / truststores) and if we ever decided to have some kind
> > of
> > > a tooling around this, e.g. in nodetool, to get a status of "how ssl is
> > > configured", we might unintentionally leak security sensitive
> information
> > > (credentials) by displaying them in plaintext in such tooling. We are
> > using
> > > JMX for this (I might expand on this if you are not familiar with that
> > > mechanism of getting runtime info from Cassandra via JMX). Hence what
> we
> > > might do is to actually not expose that map at all. We are not exposing
> > > this kind of information yet in runtime and I do not think we actually
> > have
> > > a need for that I just find it important to say.
> > >
> > > I like the fact that configuration parameters for an implementation are
> > > coupled with that factory configuration and it is just a basic map.
> Since
> > > implementations are getting their EncryptionOptions + map of customs, I
> > > prefer this instead of putting there whole map of parameters because
> then
> > > you are just again "parsing it" from map in respective constructors.
> > There
> > > is nothing wrong with how this is done in your original PR, I would
> say.
> > > The very same pattern of "maps" may be found across the code base, e.g.
> > > auditing and similar.
> > >
> > > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> > maulin.vasav...@gmail.com>
> > > wrote:
> > >
> > >> Stefan Miklosovic
> > >> 
> > >>
> > >> 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Mick Semb Wever]

Thanks for bringing this back to the ML Maulin.
Very much appreciated.

On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada 
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 
> wrote:
>
> > Stefan Miklosovic
> > 
> >
> > Hi MAULIN VASAVADA
> > , few more
> > observations. I see that you have commented again on JIRA and I am
> starting
> > to be confused where to comment in relation to recent thread we had about
> > this so I am letting you know that I am ultimately using this
> communication
> > channel for discussion.
> >
> > In the context of your latest answers on JIRA - your interface makes
> sense
> > to me, I just want to be sure that we will not forget to add anything
> which
> > would a respective implementator need in the future and could not use
> > because it is just not exposed. I am not completely sure how to solve
> this
> > but I think that we just have to stick to our gut feeling that the
> solution
> > proposed will cover the most scenarios.
> >
> > If we do not feel safe, my idea was to show yet another implementation
> > where the possibility we would left a user behind is minimised.
> Otherwise,
> > without breaking older implementations used in future releases, we could
> > only introduce methods which would have default implementations.
> >
> > I prefer to have a map instead of common encryption options. On the other
> > hand, I can imagine that the custom implementation would try to bypass
> some
> > credentials into it (for example how to connect to a respective source of
> > these keystores / truststores) and if we ever decided to have some kind
> of
> > a tooling around this, e.g. in nodetool, to get a status of "how ssl is
> > configured", we might unintentionally leak security sensitive information
> > (credentials) by displaying them in plaintext in such tooling. We are
> using
> > JMX for this (I might expand on this if you are not familiar with that
> > mechanism of getting runtime info from Cassandra via JMX). Hence what we
> > might do is to actually not expose that map at all. We are not exposing
> > this kind of information yet in runtime and I do not think we actually
> have
> > a need for that I just find it important to say.
> >
> > I like the fact that configuration parameters for an implementation are
> > coupled with that factory configuration and it is just a basic map. Since
> > implementations are getting their EncryptionOptions + map of customs, I
> > prefer this instead of putting there whole map of parameters because then
> > you are just again "parsing it" from map in respective constructors.
> There
> > is nothing wrong with how this is done in your original PR, I would say.
> > The very same pattern of "maps" may be found across the code base, e.g.
> > auditing and similar.
> >
> > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> > wrote:
> >
> >> Stefan Miklosovic
> >> 
> >>
> >> I ve taken a look too. Added some comments to PR.
> >>
> >> It would be awesome if we see some 3rd party implementation of this in
> >> action so we know it indeed works as intended. It is strange to just
> code
> >> up an interface by default logic for which it works but there isnt any
> >> (public) example how to do yet another impl.
> >>
> >> there is a directory called "examples" in the root of the repository.
> >>
> >>
> >>
> >>
> >> On Fri, Jul 9, 2021 at 2:58 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> >> wrote:
> >>
> >>> [image: maulin.vasavada]Maulin Vasavada
> >>> <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=maulin.vasavada>
> added
> >>> a comment - Yesterday - edited
> >>>
> >>> On second thoughts Stefan Miklosovic
> >>> <
> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stefan.miklosovic
> >,
> >>> I feel if we examine the interface properly and make sure of the
> contract
> >>> and dependencies - input arguments to the methods and construction of
> the
> >>> implementation (for which I agree there is no good way given an
> interface)
> >>> object AND the return types/exceptions, it could be evaluated without
> >>> sample of a specific/custom implementation. The premise is very simple
> -
> >>> Allow SSLContext (in this case JSSE's and Netty's) creation to be
> >>> pluggable. Once we do that the specific implementation should not
> matter.
> >>> However the 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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 
wrote:

> Stefan Miklosovic
> 
>
> Hi 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 
> wrote:
>
>> 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 
>> wrote:
>>
>>> [image: maulin.vasavada]Maulin Vasavada
>>> 
>>>  added
>>> a comment - Yesterday - edited
>>>
>>> On second thoughts 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Stefan Miklosovic


Hi 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 
wrote:

> 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 
> wrote:
>
>> [image: maulin.vasavada]Maulin Vasavada
>> 
>>  added
>> a comment - Yesterday - edited
>>
>> On second thoughts 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
>> )
>> 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
>> 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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 
wrote:

> [image: maulin.vasavada]Maulin Vasavada
>  
> added
> a comment - Yesterday - edited
>
> On second thoughts 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
> )
> 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
> 
>  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 
> wrote:
>
>> Hi Sumanth Pasupuleti
>> 
>>  and 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 
>> wrote:
>>
>>> [image: stefan.miklosovic]Stefan Miklosovic
>>> 
>>>  added
>>> a comment - 01/Jul/21 19:20
>>>
>>> I ve taken a look too. Added some comments to PR.
>>>
>>> It would be awesome if we see some 3rd party implementation of this in
>>> action so we know it indeed works as intended. It is strange to just code
>>> up an interface by default logic for which it works but there isnt any
>>> (public) example how to do yet another impl.
>>>
>>> On Fri, Jul 9, 2021 at 2:57 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com> wrote:
>>>
 Sumanth Pasupuleti
 
  added
 a comment - 07/Jun/21 15:13


 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

[image: maulin.vasavada]Maulin Vasavada

added
a comment - Yesterday - edited

On second thoughts 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
)
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

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 
wrote:

> Hi Sumanth Pasupuleti
> 
>  and 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 
> wrote:
>
>> [image: stefan.miklosovic]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 
>> wrote:
>>
>>> Sumanth Pasupuleti
>>> 
>>>  added
>>> a comment - 07/Jun/21 15:13
>>>
>>>
>>> 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Hi Sumanth Pasupuleti

 and 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 
wrote:

> [image: stefan.miklosovic]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 
> wrote:
>
>> Sumanth Pasupuleti
>> 
>>  added
>> a comment - 07/Jun/21 15:13
>>
>>
>> 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
>>  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 
>> wrote:
>>
>>> Hi all
>>>
>>> I wanted to consolidate a couple of comments that started in JIRA/Wiki
>>> here to keep it in one place. I'll post different posts as replies for each
>>> comment.
>>>
>>> Thanks
>>> Maulin
>>>
>>> On Tue, Jun 29, 2021 at 1:07 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com> wrote:
>>>
 ^^^ bumping up ^^^ this thread since people might have more time
 reviewing post 4.0 work. Specifically for this
 
 section in the CEP, I have coded for one option (here
 )
 and now will do for another option very soon.

 On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada <
 maulin.vasav...@gmail.com> wrote:

> Thank you Dinesh and everybody. Will keep calm and wait for the
> feedback. Meanwhile I am experimenting with various implementation options
> for what I put as "will seek community's input
> "
> on the CEP document and learning little bit more about the CircleCI.
>
> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
> 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 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

[image: stefan.miklosovic]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 
wrote:

> Sumanth Pasupuleti
> 
>  added
> a comment - 07/Jun/21 15:13
>
>
> 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
>  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 
> wrote:
>
>> Hi all
>>
>> I wanted to consolidate a couple of comments that started in JIRA/Wiki
>> here to keep it in one place. I'll post different posts as replies for each
>> comment.
>>
>> Thanks
>> Maulin
>>
>> On Tue, Jun 29, 2021 at 1:07 PM Maulin Vasavada <
>> maulin.vasav...@gmail.com> wrote:
>>
>>> ^^^ bumping up ^^^ this thread since people might have more time
>>> reviewing post 4.0 work. Specifically for this
>>> 
>>> section in the CEP, I have coded for one option (here
>>> )
>>> and now will do for another option very soon.
>>>
>>> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com> wrote:
>>>
 Thank you Dinesh and everybody. Will keep calm and wait for the
 feedback. Meanwhile I am experimenting with various implementation options
 for what I put as "will seek community's input
 "
 on the CEP document and learning little bit more about the CircleCI.

 On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
 wrote:

> Hi Maulin,
>
> Thank you for the CEP & Patch. I’ve been following along albeit
> silently. Will take a look. It’s just that we’re currently busy so bear
> with us.
>
> Thanks,
>
> Dinesh
>
> > On Jun 2, 2021, at 3:28 PM, Maulin Vasavada <
> maulin.vasav...@gmail.com> wrote:
> >
> > Hi all
> >
> > ^^^ bump ^^^ I've raised the PR and am waiting for the review. Once
> I see
> > that the suggested changes are directionally right I'll start a VOTE
> thread
> > on the CEP (unless I am recommended to follow another process).
> >
> > Thanks
> > Maulin
> >
> >> On Thu, May 27, 2021 at 1:29 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> >> wrote:
> >>
> >> HI all
> >>
> >> I've raised the PR with the changes. Specifically I would
> appreciate the
> >> community's input on this section of the CEP
> >> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations
> >
> >> .
> >>
> >> Once we get some consensus on the PR (except minor code improvement
> >> suggestions) I'll start a VOTE thread for the CEP.
> >>
> >> I thank all 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Sumanth Pasupuleti

added
a comment - 07/Jun/21 15:13


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
 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 
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 
> wrote:
>
>> ^^^ bumping up ^^^ this thread since people might have more time
>> reviewing post 4.0 work. Specifically for this
>> 
>> section in the CEP, I have coded for one option (here
>> )
>> and now will do for another option very soon.
>>
>> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada 
>> 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
>>> "
>>> on the CEP document and learning little bit more about the CircleCI.
>>>
>>> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
>>> wrote:
>>>
 Hi Maulin,

 Thank you for the CEP & Patch. I’ve been following along albeit
 silently. Will take a look. It’s just that we’re currently busy so bear
 with us.

 Thanks,

 Dinesh

 > On Jun 2, 2021, at 3:28 PM, Maulin Vasavada <
 maulin.vasav...@gmail.com> wrote:
 >
 > Hi all
 >
 > ^^^ bump ^^^ I've raised the PR and am waiting for the review. Once I
 see
 > that the suggested changes are directionally right I'll start a VOTE
 thread
 > on the CEP (unless I am recommended to follow another process).
 >
 > Thanks
 > Maulin
 >
 >> On Thu, May 27, 2021 at 1:29 PM Maulin Vasavada <
 maulin.vasav...@gmail.com>
 >> wrote:
 >>
 >> HI all
 >>
 >> I've raised the PR with the changes. Specifically I would appreciate
 the
 >> community's input on this section of the CEP
 >> <
 https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations
 >
 >> .
 >>
 >> Once we get some consensus on the PR (except minor code improvement
 >> suggestions) I'll start a VOTE thread for the CEP.
 >>
 >> I thank all the reviewers of the CEP and the PR in advance and am
 >> completely excited to contribute to Apache Cassandra.
 >>
 >> Thanks
 >> Maulin
 >>
 >> On Thu, May 27, 2021 at 11:04 AM Maulin Vasavada <
 >> maulin.vasav...@gmail.com> wrote:
 >>
 >>> Sounds good Brandon. I'll raise the PR in a couple of hours from
 now.
 >>> Thanks.
 >>>
 >>> On Thu, May 27, 2021 at 10:14 AM Brandon Williams >>> >
 >>> 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
 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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 
wrote:

> ^^^ bumping up ^^^ this thread since people might have more time reviewing
> post 4.0 work. Specifically for this
> 
> section in the CEP, I have coded for one option (here
> )
> and now will do for another option very soon.
>
> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada 
> 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
>> "
>> on the CEP document and learning little bit more about the CircleCI.
>>
>> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
>> 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 
>>> wrote:
>>> >
>>> > Hi all
>>> >
>>> > ^^^ bump ^^^ I've raised the PR and am waiting for the review. Once I
>>> see
>>> > that the suggested changes are directionally right I'll start a VOTE
>>> thread
>>> > on the CEP (unless I am recommended to follow another process).
>>> >
>>> > Thanks
>>> > Maulin
>>> >
>>> >> On Thu, May 27, 2021 at 1:29 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com>
>>> >> wrote:
>>> >>
>>> >> HI all
>>> >>
>>> >> I've raised the PR with the changes. Specifically I would appreciate
>>> the
>>> >> community's input on this section of the CEP
>>> >> <
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations
>>> >
>>> >> .
>>> >>
>>> >> Once we get some consensus on the PR (except minor code improvement
>>> >> suggestions) I'll start a VOTE thread for the CEP.
>>> >>
>>> >> I thank all the reviewers of the CEP and the PR in advance and am
>>> >> completely excited to contribute to Apache Cassandra.
>>> >>
>>> >> Thanks
>>> >> Maulin
>>> >>
>>> >> On Thu, May 27, 2021 at 11:04 AM Maulin Vasavada <
>>> >> maulin.vasav...@gmail.com> wrote:
>>> >>
>>> >>> Sounds good Brandon. I'll raise the PR in a couple of hours from now.
>>> >>> Thanks.
>>> >>>
>>> >>> On Thu, May 27, 2021 at 10:14 AM Brandon Williams 
>>> >>> 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
>>>   wrote:
>>> >
>>> > Hi all
>>> >
>>> > I think I am close to raising a PR now but my CircleCI job
>>> > <
>>> https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra>
>>> > doesn't make progress beyond key tasks success like unit tests,
>>> dtests,
>>> > cqlshlibtests. Any recommendation on if we need to see the whole
>>>  CircleCI
>>> > job green before raising the PR?
>>> >
>>> > Thanks
>>> > Maulin
>>> >
>>> > On Fri, May 21, 2021 at 8:54 PM Maulin Vasavada <
>>>  maulin.vasav...@gmail.com>
>>> > wrote:
>>> >
>>> >> I am almost done with all changes except the code snippet in the
>>> >> EncryptioOptions.java which determines 'enabled' and 'optional'
>>>  encryption
>>> >> flags. Will raise the PR soon once I see my CircleCI getting
>>> green.
>>> >>
>>> >> On Fri, May 21, 2021 at 9:24 AM Maulin Vasavada <
>>>  maulin.vasav...@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> FYI - I am working on PR. I made some changes and trying to run
>>>  tests.
>>> >>>
>>> >>> On Tue, May 18, 2021 at 10:14 PM Maulin Vasavada <
>>> >>> maulin.vasav...@gmail.com> wrote:
>>> >>>
>>>  Thanks Nate for reviewing the CEP. Yes for change #3 in the
>>> CEP, I
>>>  mean
>>>  to have only single Default Impl and that would be a final
>>> class,
>>>  not
>>>  overridable. It will be basically an internal implementation.
>>> I've
>>>  updated
>>>  the CEP to reflect this.
>>> 
>>>  On Tue, May 18, 2021 at 7:21 PM Nate McCall >> >
>>>  wrote:
>>> 
>>> > Hi Maulin,
>>> > Thanks for putting this together!
>>> >
>>> > Took a quick glance, 

Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

^^^ bumping up ^^^ this thread since people might have more time reviewing
post 4.0 work. Specifically for this

section in the CEP, I have coded for one option (here
)
and now will do for another option very soon.

On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada 
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
> "
> on the CEP document and learning little bit more about the CircleCI.
>
> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
> 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 
>> wrote:
>> >
>> > Hi all
>> >
>> > ^^^ bump ^^^ I've raised the PR and am waiting for the review. Once I
>> see
>> > that the suggested changes are directionally right I'll start a VOTE
>> thread
>> > on the CEP (unless I am recommended to follow another process).
>> >
>> > Thanks
>> > Maulin
>> >
>> >> On Thu, May 27, 2021 at 1:29 PM Maulin Vasavada <
>> maulin.vasav...@gmail.com>
>> >> wrote:
>> >>
>> >> HI all
>> >>
>> >> I've raised the PR with the changes. Specifically I would appreciate
>> the
>> >> community's input on this section of the CEP
>> >> <
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations
>> >
>> >> .
>> >>
>> >> Once we get some consensus on the PR (except minor code improvement
>> >> suggestions) I'll start a VOTE thread for the CEP.
>> >>
>> >> I thank all the reviewers of the CEP and the PR in advance and am
>> >> completely excited to contribute to Apache Cassandra.
>> >>
>> >> Thanks
>> >> Maulin
>> >>
>> >> On Thu, May 27, 2021 at 11:04 AM Maulin Vasavada <
>> >> maulin.vasav...@gmail.com> wrote:
>> >>
>> >>> Sounds good Brandon. I'll raise the PR in a couple of hours from now.
>> >>> Thanks.
>> >>>
>> >>> On Thu, May 27, 2021 at 10:14 AM Brandon Williams 
>> >>> 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
>>   wrote:
>> >
>> > Hi all
>> >
>> > I think I am close to raising a PR now but my CircleCI job
>> > <
>> https://app.circleci.com/pipelines/github/maulin-vasavada/cassandra>
>> > doesn't make progress beyond key tasks success like unit tests,
>> dtests,
>> > cqlshlibtests. Any recommendation on if we need to see the whole
>>  CircleCI
>> > job green before raising the PR?
>> >
>> > Thanks
>> > Maulin
>> >
>> > On Fri, May 21, 2021 at 8:54 PM Maulin Vasavada <
>>  maulin.vasav...@gmail.com>
>> > wrote:
>> >
>> >> I am almost done with all changes except the code snippet in the
>> >> EncryptioOptions.java which determines 'enabled' and 'optional'
>>  encryption
>> >> flags. Will raise the PR soon once I see my CircleCI getting green.
>> >>
>> >> On Fri, May 21, 2021 at 9:24 AM Maulin Vasavada <
>>  maulin.vasav...@gmail.com>
>> >> wrote:
>> >>
>> >>> FYI - I am working on PR. I made some changes and trying to run
>>  tests.
>> >>>
>> >>> On Tue, May 18, 2021 at 10:14 PM Maulin Vasavada <
>> >>> maulin.vasav...@gmail.com> wrote:
>> >>>
>>  Thanks Nate for reviewing the CEP. Yes for change #3 in the CEP,
>> I
>>  mean
>>  to have only single Default Impl and that would be a final class,
>>  not
>>  overridable. It will be basically an internal implementation.
>> I've
>>  updated
>>  the CEP to reflect this.
>> 
>>  On Tue, May 18, 2021 at 7:21 PM Nate McCall 
>>  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