Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a nested structure around major database concepts

[Maulin Vasavada]

Great discussion.

It would be an implementation detail but we could imagine having a single
interface for reading config and providing readers for old or/and new
configuration formats. If we can streamline reading of all configs from
that single interface we would have much centralized (following the Single
Responsibility Principle) changes to track/review and test.

Thanks
Maulin

On Wed, Feb 23, 2022 at 11:47 AM Jeremy Hanna 
wrote:

> If we support both formats for a time, I just would want to make
> absolutely sure that it will read only one or the other so there's no
> uncertainty about the server configuration.  Perhaps to avoid unforeseen
> migration problems, we only read the old format if a specific flag is set?
> So with version 5, we only read the new format by default.  So if you only
> have the old format and you try to start 5.0, it will fail with a log
> message about a JVM option to be used ("READ_CASSANDRA_YAML" or
> something).  So if you enable that, you *only* read the old config.  It
> would be one or the other so you don't have weird dilemmas of which one to
> choose.
>
> On Feb 23, 2022, at 11:30 AM, Caleb Rackliffe 
> wrote:
>
> 
> Continuing to parse the old format for some time seems unavoidable, and
> allowing dot-separated options in the old format seems reasonable.
>
> There will certainly be some interesting problems when we move into
> implementation space with this. One approach might be to implement a clean
> object model that corresponds to the new format, work out how it's
> parsed/populated from the file, and then have some kind of converter from
> the old Config object to the new object model that allows us to provide
> values to DatabaseDescriptor from only the new one (thereby avoiding any
> changes to the places all over the codebase that use DD).
>
> On Wed, Feb 23, 2022 at 4:46 AM Bowen Song  wrote:
>
>> I agree with Benedict, there's legit use cases for both the flat and
>> structured config file format. The operator should be able to choose which
>> one is best suited for their own use case. It will also make the upgrade
>> process easier if both formats are supported by future versions of
>> Cassandra.
>> On 23/02/2022 07:52, bened...@apache.org wrote:
>>
>> I agree that a new configuration layout should be introduced once only,
>> not incrementally.
>>
>>
>>
>> However, I disagree that we should immediately deprecate the old config
>> file and refuse to parse it. We can maintain compatibility indefinitely at
>> low cost, so we should do so.
>>
>>
>>
>> Users of the old format, when using new configuration options, can simply
>> use dot separators to specify them. Since most settings are not required,
>> this is by far the least painful upgrade process.
>>
>>
>>
>>
>>
>> *From: *Berenguer Blasi 
>> 
>> *Date: *Wednesday, 23 February 2022 at 06:53
>> *To: *dev@cassandra.apache.org 
>> 
>> *Subject: *Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a
>> nested structure around major database concepts
>>
>> +1 to a non-incremental approach as well.
>>
>> On 23/2/22 1:27, Caleb Rackliffe wrote:
>> > @Patrick I’m absolutely intending for this to be a 5.0 concern. The
>> only reason why it would have any bearing on 4.x is the case where we’re
>> adding new config that could fit into the v2 structure now and not require
>> any later changes.
>> >
>> >> On Feb 22, 2022, at 3:22 PM, Bernardo Sanchez
>>   wrote:
>> >>
>> >> unsubscribe
>> >>
>> >> -Original Message-
>> >> From: Stefan Miklosovic 
>> 
>> >> Sent: Tuesday, February 22, 2022 3:53 PM
>> >> To: dev@cassandra.apache.org
>> >> Subject: Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a
>> nested structure around major database concepts
>> >>
>> >> "EXTERNAL EMAIL" - This email originated from outside of the
>> organization. Do not click or open attachments unless you recognize the
>> sender and know the content is safe. If you are unsure, please contact
>> hel...@pointclickcare.com.
>> >>
>> >> I want to add that to, however, on the other hand, we also do have
>> dtests in Python and they need to run with old configs too. That is what
>> Ekaterina was doing - supporting old configuration while introducing new
>> one. If we make "a big cut" and old way of doing things would not be
>> possible, how are we going to treat this in dtests when we will have stuff
>> for 3.11, 4 on old configs and 5 on new configs?
>> >>
>> >>> On Tue, 22 Feb 2022 at 21:48, Stefan Miklosovic
>>  
>> wrote:
>> >>>
>> >>> +1 to what Patrick says.
>> >>>
>>  On Tue, 22 Feb 2022 at 21:40, Patrick McFadin 
>>  wrote:
>> 
>>  I'm going to put up a red flag of making config file changes of this
>> scale on a dot release. This should really be a 5.0 consideration.
>> 
>>  With that, I would propose a #5. 5.0 nodes will only read the new
>> config files and reject old config files. If any of you went through the
>> config file changes from Apache HTTPd 1.3 -> 2.0 you know how much of a
>> lifesaver 

Re: Build tool

[Maulin Vasavada]

On the onboarding new contributors I can definitely say that I agree with
the earlier comment about 'getting surprised to see ant' (having worked on
Maven and Gradle for the last 10+ years). Also, I would recount a specific
challenge I had with making the 'examples' folder as a sub-module in
IntelliJ. Not sure if it was Maven, it would simplify anything because I
felt it was partly IntelliJ's caching that gave me a lot of trouble until I
figured out how to make it work predictably for the sub-module. Without
that setup I could not run unit tests from the examples/ssl-factory folder
from the IntelliJ.

Agree that we should prepare pros/cons and have a choice vote.

On Thu, Feb 3, 2022 at 8:05 AM bened...@apache.org 
wrote:

> +1
>
>
>
> If we can get a pros/cons list we can have a ranked choice vote, move
> forwards, and maybe agree not to revisit this for a few years at least?
>
>
>
>
>
> *From: *Joshua McKenzie 
> *Date: *Thursday, 3 February 2022 at 13:59
> *To: *dev 
> *Subject: *Re: Build tool
>
> Could someone take on clearly enumerating the pros and cons of ant vs.
> maven?
>
>
>
> Without clarity this is going to keep stagnating as a war of
> unsubstantiated opinions and fizzle out like it has so many times in the
> past.
>
>
>
> I'd like to see it either change or the topic be put to rest. :)
>
>
>
>
>
> On Thu, Feb 3, 2022 at 8:38 AM Brandon Williams  wrote:
>
> On Thu, Feb 3, 2022 at 7:19 AM bened...@apache.org 
> wrote:
> > It pretends to be Maven for dependency management, but this is a small
> part of the job of a build file.
>
> It doesn't pretend, it actually uses part of the Maven project to
> accomplish its goals.  It's half the Maven it could be.
>
>

Re: Build tool

[Maulin Vasavada]

Hi Aleksei

I was thinking about the same - build tool. I have used both - Maven and
Gradle. In my experience, while Gradle has a rich DSL and the corresponding
power, with constant changes in Gradle across versions it is difficult to
focus on the actual product (like Cassandra in this case) development. With
Maven the learning is once and it doesn't change that much and one can
focus on the actual product better.

Of course, this is IMHO. +1 for using Maven. I would like to participate in
the migration of the build tool if it needs more hands.

Thanks
Maulin

On Wed, Feb 2, 2022 at 2:35 PM Aleksei Zotov  wrote:

> Hi All,
>
> Some time ago I created
> https://issues.apache.org/jira/browse/CASSANDRA-17015 to migrate from ant
> to maven/gradle. Originally I was going to implement both, compare and pick
> the best in terms of project needs. However, now I feel it would be a
> significant overhead to try out both. Therefore, I'd like to make a
> collective decision on the build tool before starting any actual work.
>
> I saw on Slack (
> https://app.slack.com/client/T4S1WH2J3/CK23JSY2K/thread/CK23JSY2K-1643748908.929809)
> that many people prefer maven. I'm leaning towards maven as well.
>
> I guess we need to have a formal poll on the build tool since it is a
> significant part of the project. Please, suggest what the best way to
> proceed is. Should I just raise a vote for maven and just see if someone -1
> in favor of gradle?
>
> PS:
> Please, bear in mind that Robert has already made some progress on gradle
> migration. I do not know how much is done there and whether he is willing
> to get it completed.
>
> On 2020/06/02 13:39:34 Robert Stupp wrote:
> > Yea - it's already in a pretty good state.
> >
> > Some work-in-progress-state is already available in either
> > https://github.com/snazy/cassandra/tree/tryout-gradle (or
> > https://github.com/snazy/cassandra/tree/tryout-gradle-dist-test with an
> > additional commit).
> >
> > I already use it on my machine for a bunch of things and it already
> > "feels bad" to go back to a branch without Gradle.
> >
> > I'll start a separate dev-ML thread with some more information in the
> > next days, because getting C* 4.0-beta released is a higher priority atm.
> >
> > On 6/1/20 2:41 AM, Joshua McKenzie wrote:
> > > Build tools are like religions, that's why. Or maybe cults. Or all
> > > Stockholm Syndrome creators? :)
> > >
> > > Robert Stupp has been noodling around with a gradle based build env
> for C*
> > > that'll live alongside ant. Not sure what the status is on that atm
> through.
> > >
> > > On Sun, May 31, 2020 at 3:16 PM Abhishek Singh 
> wrote:
> > >
> > >> Hi All,
> > >>Hope you are doing well and are safe.
> > >>   I just wanted to know why is the build still on ant and is there
> any plan
> > >> to migrate to a modern build tool?
> > >>
> > >> Regards,
> > >> Abhishek Singh
> > >>
> > --
> > Robert Stupp
> > @snazy
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

[Maulin Vasavada]

Basically, we also have to think about how operable these changes will be
for operators in multi-tenant, multi-cluster/dc environments w.r.t. key
rotations, security, key deployments etc.

On Fri, Nov 19, 2021 at 8:03 PM Maulin Vasavada 
wrote:

> Hi all
>
> Really interesting discussion. I started reading this thread and still
> have to catch-up a lot but based on my experience many big organizations
> ultimately settle on having over-the-wire encryption combined with OS/disk
> encryption to comply with the security requirements for various reasons
> like,
> 1. Potential performance challenges at high scale of data
> movement/mirroring
> 2. Internal security groups/zoning structures and restrictions (like
> restrictions on key sharing between zones etc which makes
> mirroring/replication for cross-zone impossible)
> 3. Management/maintenance of the in-house Key Management System is quite a
> challenging overhead for on-prem installations and when things move to
> cloud, ultimately organizations opt-in for the cloud provider's on-disk
> encryption and having over-the-wire encryption with TLS or using SASL over
> SSL because the whole application migration/adoption becomes multi-year
> challenging program.
>
> We experienced challenges even with AES-NI/JDK9+/Kernel TLS on Linux but
> that was because we were looking at per-message (in Kafka world) encryption
> with asymmetric envelope so it could be off the context here.
>
> None-the-less I will read the thread in more detail just to gain more
> knowledge, it has been really a great technical discussion.
>
> Thanks
> Maulin
>
>
>
>
> On Fri, Nov 19, 2021 at 2:05 PM Kokoori, Shylaja <
> shylaja.koko...@intel.com> wrote:
>
>> I agree with Joey, kernel also should be able to take advantage of the
>> crypto acceleration.
>>
>> I also want to add, since performance of JDK is a concern here, newer
>> Intel Icelake server platforms supports VAES and SHA-NI which further
>> accelerates AES-GCM perf by 2x and SHA1 perf by ~6x using JDK 11.
>>
>> Some configuration information for the tests I ran.
>>
>> - JDK version used was JDK14 (should behave similarly with JDK11
>> also).
>> - Since the tests were done before 4.0 GA'd, Cassandra version used
>> was 4.0-beta3. Dataset size was ~500G
>> - Workloads tested were 100% reads, 100% updates & 80:20 mix with
>> cassandra-stress. I have not tested streaming yet.
>>
>> I would be happy to provide additional data points or make necessary code
>> changes based on recommendations from folks here.
>>
>> Thanks,
>> Shylaja
>>
>> -Original Message-
>> From: Joshua McKenzie 
>> Sent: Friday, November 19, 2021 4:53 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: Resurrection of CASSANDRA-9633 - SSTable encryption
>>
>> >
>> > setting performance requirements on this regard is a nonsense. As long
>> > as it's reasonably usable in real world, and Cassandra makes the
>> > estimated effects on performance available, it will be up to the
>> > operators to decide whether to turn on the feature
>>
>> I think Joey's argument, and correct me if I'm wrong, is that
>> implementing a complex feature in Cassandra that we then have to manage
>> that's essentially worse in every way compared to a built-in full-disk
>> encryption option via LUKS+LVM etc is a poor use of our time and energy.
>>
>> i.e. we'd be better off investing our time into documenting how to do
>> full disk encryption in a variety of scenarios + explaining why that is our
>> recommended approach instead of taking the time and energy to design,
>> implement, debug, and then maintain an inferior solution.
>>
>> On Fri, Nov 19, 2021 at 7:49 AM Joshua McKenzie 
>> wrote:
>>
>> > Are you for real here?
>> >
>> > Please keep things cordial. Statements like this don't help move the
>> > conversation along.
>> >
>> >
>> > On Fri, Nov 19, 2021 at 3:57 AM Stefan Miklosovic <
>> > stefan.mikloso...@instaclustr.com> wrote:
>> >
>> >> On Fri, 19 Nov 2021 at 02:51, Joseph Lynch 
>> wrote:
>> >> >
>> >> > On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja <
>> >> shylaja.koko...@intel.com>
>> >> > wrote:
>> >> >
>> >> > > To address Joey's concern, the OpenJDK JVM and its derivatives
>> >> optimize
>> >> > > Java crypto based on the underlying HW capabilities. For example,
>> >>

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

[Maulin Vasavada]

Hi all

Really interesting discussion. I started reading this thread and still have
to catch-up a lot but based on my experience many big organizations
ultimately settle on having over-the-wire encryption combined with OS/disk
encryption to comply with the security requirements for various reasons
like,
1. Potential performance challenges at high scale of data movement/mirroring
2. Internal security groups/zoning structures and restrictions (like
restrictions on key sharing between zones etc which makes
mirroring/replication for cross-zone impossible)
3. Management/maintenance of the in-house Key Management System is quite a
challenging overhead for on-prem installations and when things move to
cloud, ultimately organizations opt-in for the cloud provider's on-disk
encryption and having over-the-wire encryption with TLS or using SASL over
SSL because the whole application migration/adoption becomes multi-year
challenging program.

We experienced challenges even with AES-NI/JDK9+/Kernel TLS on Linux but
that was because we were looking at per-message (in Kafka world) encryption
with asymmetric envelope so it could be off the context here.

None-the-less I will read the thread in more detail just to gain more
knowledge, it has been really a great technical discussion.

Thanks
Maulin




On Fri, Nov 19, 2021 at 2:05 PM Kokoori, Shylaja 
wrote:

> I agree with Joey, kernel also should be able to take advantage of the
> crypto acceleration.
>
> I also want to add, since performance of JDK is a concern here, newer
> Intel Icelake server platforms supports VAES and SHA-NI which further
> accelerates AES-GCM perf by 2x and SHA1 perf by ~6x using JDK 11.
>
> Some configuration information for the tests I ran.
>
> - JDK version used was JDK14 (should behave similarly with JDK11
> also).
> - Since the tests were done before 4.0 GA'd, Cassandra version used
> was 4.0-beta3. Dataset size was ~500G
> - Workloads tested were 100% reads, 100% updates & 80:20 mix with
> cassandra-stress. I have not tested streaming yet.
>
> I would be happy to provide additional data points or make necessary code
> changes based on recommendations from folks here.
>
> Thanks,
> Shylaja
>
> -Original Message-
> From: Joshua McKenzie 
> Sent: Friday, November 19, 2021 4:53 AM
> To: dev@cassandra.apache.org
> Subject: Re: Resurrection of CASSANDRA-9633 - SSTable encryption
>
> >
> > setting performance requirements on this regard is a nonsense. As long
> > as it's reasonably usable in real world, and Cassandra makes the
> > estimated effects on performance available, it will be up to the
> > operators to decide whether to turn on the feature
>
> I think Joey's argument, and correct me if I'm wrong, is that implementing
> a complex feature in Cassandra that we then have to manage that's
> essentially worse in every way compared to a built-in full-disk encryption
> option via LUKS+LVM etc is a poor use of our time and energy.
>
> i.e. we'd be better off investing our time into documenting how to do full
> disk encryption in a variety of scenarios + explaining why that is our
> recommended approach instead of taking the time and energy to design,
> implement, debug, and then maintain an inferior solution.
>
> On Fri, Nov 19, 2021 at 7:49 AM Joshua McKenzie 
> wrote:
>
> > Are you for real here?
> >
> > Please keep things cordial. Statements like this don't help move the
> > conversation along.
> >
> >
> > On Fri, Nov 19, 2021 at 3:57 AM Stefan Miklosovic <
> > stefan.mikloso...@instaclustr.com> wrote:
> >
> >> On Fri, 19 Nov 2021 at 02:51, Joseph Lynch 
> wrote:
> >> >
> >> > On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja <
> >> shylaja.koko...@intel.com>
> >> > wrote:
> >> >
> >> > > To address Joey's concern, the OpenJDK JVM and its derivatives
> >> optimize
> >> > > Java crypto based on the underlying HW capabilities. For example,
> >> > > if
> >> the
> >> > > underlying HW supports AES-NI, JVM intrinsics will use those for
> >> crypto
> >> > > operations. Likewise, the new vector AES available on the latest
> >> > > Intel platform is utilized by the JVM while running on that
> >> > > platform to make crypto operations faster.
> >> > >
> >> >
> >> > Which JDK version were you running? We have had a number of issues
> >> > with
> >> the
> >> > JVM being 2-10x slower than native crypto on Java 8 (especially
> >> > MD5,
> >> SHA1,
> >> > and AES-GCM) and to a lesser extent Java 11 (usually ~2x slower).
> >> > Again
> >> I
> >> > think we could get the JVM crypto penalty down to ~2x native if we
> >> linked
> >> > in e.g. ACCP by default [1, 2] but even the very best Java crypto
> >> > I've
> >> seen
> >> > (fully utilizing hardware instructions) is still ~2x slower than
> >> > native code. The operating system has a number of advantages here
> >> > in that they don't pay JVM allocation costs or the JNI barrier (in
> >> > the case of ACCP)
> >> and
> >> > the kernel also takes advantage of hardware instructions.
> >> >
> >> 

Re: [DISCUSS] CASSANDRA-17031: Add support for PEM based key material for SSL

[Maulin Vasavada]

+1 Dinesh. It will be like that. For client and server both encryption
options you can choose different key material types. I'll raise a PR soon
and you can check the tests I've.

Thanks
Maulin

On Tue, Oct 12, 2021 at 9:22 PM Dinesh Joshi 
wrote:

> On 10/11/21 12:34 PM, Maulin Vasavada wrote:
> > Dinesh, when you say PEM and JKS formats simultaneously, do you mean that
> > for client vs internnode ssl we should be able to use different formats
> OR
> > beyond that within particular encryption options have a combination - PEM
> > based private keys and JKS based truststore?
>
> Currently, Cassandra has two configuration blocks one for the client
> (client_encryption_options) and the other for the internode
> (server_encryption_options). Both blocks individually can specify a
> different type of truststore. Currently it only supports the stores that
> are supported by Java's standard stores like JKS and PKCS12. If you plan
> on adding new types, then lets make sure that we continue supporting
> these types and support PEM in addition.
>
> Dinesh
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CASSANDRA-17031: Add support for PEM based key material for SSL

[Maulin Vasavada]

Hi Derek

I am not sure what you are trying to do. Are you trying to delete the CEP
page OR trying to see/edit the JIRA ticket? Anybody else have a clue what
Derek is running into?

Thanks
Maulin

On Mon, Oct 11, 2021 at 2:34 PM Derek Chen-Becker 
wrote:

> Hi Maulin,
>
> I'm getting a permission denied error when I try to access the ticket. What
> do I need to do to get access?
>
> Thanks,
>
> Derek
>
> On Mon, Oct 11, 2021 at 1:34 PM Maulin Vasavada  >
> wrote:
>
> > Changing the subject for this discussion with the JIRA ticket now.
> >
> > Dinesh, when you say PEM and JKS formats simultaneously, do you mean that
> > for client vs internnode ssl we should be able to use different formats
> OR
> > beyond that within particular encryption options have a combination - PEM
> > based private keys and JKS based truststore?
> >
> > Thanks
> > Maulin
> >
> > On Mon, Oct 11, 2021 at 12:02 PM Maulin Vasavada <
> > maulin.vasav...@gmail.com>
> > wrote:
> >
> > > Thanks all for your responses. So I'll give back the CEP number (if I
> > > can).
> > >
> > > For Dinesh's comment, I think we can take up in the DISCUSS thread for
> > the
> > > JIRA ticket that I'll start. I will make sure I understand his comment
> > and
> > > resolve it correctly.
> > >
> > > Thanks
> > > Maulin
> > >
> > > On Mon, Oct 11, 2021 at 8:47 AM Dinesh Joshi
>  > >
> > > wrote:
> > >
> > >> This could be just an enhancement jira. No need for a CEP.
> > >>
> > >> I think this would be a fine addition to Cassandra. Please ensure that
> > we
> > >> can support both PEM as well as the current JKS simultaneously.
> > >>
> > >> Dinesh
> > >>
> > >> > On Oct 11, 2021, at 3:06 AM, Stefan Miklosovic <
> > >> stefan.mikloso...@instaclustr.com> wrote:
> > >> >
> > >> > I agree with Benedict, this does not need to have its own CEP.
> > >> >
> > >> > In the "approach" section to-be-discussed CEP-17, I clearly see this
> > >> > is building on top of what is already in so I do not think this
> needs
> > >> > yet another CEP to materialize.
> > >> >
> > >> > Regards
> > >> >
> > >> >> On Mon, 11 Oct 2021 at 12:00, bened...@apache.org <
> > bened...@apache.org>
> > >> wrote:
> > >> >>
> > >> >> Hi Maulin,
> > >> >>
> > >> >> This sounds fine to me, though I don’t consider myself well versed
> in
> > >> these system details.
> > >> >>
> > >> >> I have a meta comment though: I think this could easily have been a
> > >> Jira with a DISCUSS thread brought to the list. The CEP process is (in
> > my
> > >> opinion) for complex decisions that needs broad consent from the
> > community,
> > >> whereas this seems like a straightforward feature we might want to
> > >> advertise to ensure others have an opportunity to offer their
> expertise
> > and
> > >> opinions on.
> > >> >>
> > >> >>
> > >> >> From: Maulin Vasavada 
> > >> >> Date: Monday, 11 October 2021 at 06:54
> > >> >> To: dev@cassandra.apache.org 
> > >> >> Subject: [DISCUSS] CEP-17: Add support for PEM based key material
> for
> > >> SSL
> > >> >> Hi all,
> > >> >>
> > >> >> I would like to start this discussion thread for the CEP-17
> > >> >> <
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+Add+support+for+PEM+based+key+material+for+SSL
> > >> >.
> > >> >> I think it would be a great addition to support a commonly used
> > format
> > >> for
> > >> >> private keys and trusted certificates for SSL configurations.
> > >> >>
> > >> >> Thank you.
> > >> >> Maulin
> > >> >
> > >> >
> -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >> >
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> >
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>

[DISCUSS] CASSANDRA-17031: Add support for PEM based key material for SSL

[Maulin Vasavada]

Changing the subject for this discussion with the JIRA ticket now.

Dinesh, when you say PEM and JKS formats simultaneously, do you mean that
for client vs internnode ssl we should be able to use different formats OR
beyond that within particular encryption options have a combination - PEM
based private keys and JKS based truststore?

Thanks
Maulin

On Mon, Oct 11, 2021 at 12:02 PM Maulin Vasavada 
wrote:

> Thanks all for your responses. So I'll give back the CEP number (if I
> can).
>
> For Dinesh's comment, I think we can take up in the DISCUSS thread for the
> JIRA ticket that I'll start. I will make sure I understand his comment and
> resolve it correctly.
>
> Thanks
> Maulin
>
> On Mon, Oct 11, 2021 at 8:47 AM Dinesh Joshi 
> wrote:
>
>> This could be just an enhancement jira. No need for a CEP.
>>
>> I think this would be a fine addition to Cassandra. Please ensure that we
>> can support both PEM as well as the current JKS simultaneously.
>>
>> Dinesh
>>
>> > On Oct 11, 2021, at 3:06 AM, Stefan Miklosovic <
>> stefan.mikloso...@instaclustr.com> wrote:
>> >
>> > I agree with Benedict, this does not need to have its own CEP.
>> >
>> > In the "approach" section to-be-discussed CEP-17, I clearly see this
>> > is building on top of what is already in so I do not think this needs
>> > yet another CEP to materialize.
>> >
>> > Regards
>> >
>> >> On Mon, 11 Oct 2021 at 12:00, bened...@apache.org 
>> wrote:
>> >>
>> >> Hi Maulin,
>> >>
>> >> This sounds fine to me, though I don’t consider myself well versed in
>> these system details.
>> >>
>> >> I have a meta comment though: I think this could easily have been a
>> Jira with a DISCUSS thread brought to the list. The CEP process is (in my
>> opinion) for complex decisions that needs broad consent from the community,
>> whereas this seems like a straightforward feature we might want to
>> advertise to ensure others have an opportunity to offer their expertise and
>> opinions on.
>> >>
>> >>
>> >> From: Maulin Vasavada 
>> >> Date: Monday, 11 October 2021 at 06:54
>> >> To: dev@cassandra.apache.org 
>> >> Subject: [DISCUSS] CEP-17: Add support for PEM based key material for
>> SSL
>> >> Hi all,
>> >>
>> >> I would like to start this discussion thread for the CEP-17
>> >> <
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+Add+support+for+PEM+based+key+material+for+SSL
>> >.
>> >> I think it would be a great addition to support a commonly used format
>> for
>> >> private keys and trusted certificates for SSL configurations.
>> >>
>> >> Thank you.
>> >> Maulin
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>

Re: [DISCUSS] CEP-17: Add support for PEM based key material for SSL

[Maulin Vasavada]

Thanks all for your responses. So I'll give back the CEP number (if I can).

For Dinesh's comment, I think we can take up in the DISCUSS thread for the
JIRA ticket that I'll start. I will make sure I understand his comment and
resolve it correctly.

Thanks
Maulin

On Mon, Oct 11, 2021 at 8:47 AM Dinesh Joshi 
wrote:

> This could be just an enhancement jira. No need for a CEP.
>
> I think this would be a fine addition to Cassandra. Please ensure that we
> can support both PEM as well as the current JKS simultaneously.
>
> Dinesh
>
> > On Oct 11, 2021, at 3:06 AM, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
> >
> > I agree with Benedict, this does not need to have its own CEP.
> >
> > In the "approach" section to-be-discussed CEP-17, I clearly see this
> > is building on top of what is already in so I do not think this needs
> > yet another CEP to materialize.
> >
> > Regards
> >
> >> On Mon, 11 Oct 2021 at 12:00, bened...@apache.org 
> wrote:
> >>
> >> Hi Maulin,
> >>
> >> This sounds fine to me, though I don’t consider myself well versed in
> these system details.
> >>
> >> I have a meta comment though: I think this could easily have been a
> Jira with a DISCUSS thread brought to the list. The CEP process is (in my
> opinion) for complex decisions that needs broad consent from the community,
> whereas this seems like a straightforward feature we might want to
> advertise to ensure others have an opportunity to offer their expertise and
> opinions on.
> >>
> >>
> >> From: Maulin Vasavada 
> >> Date: Monday, 11 October 2021 at 06:54
> >> To: dev@cassandra.apache.org 
> >> Subject: [DISCUSS] CEP-17: Add support for PEM based key material for
> SSL
> >> Hi all,
> >>
> >> I would like to start this discussion thread for the CEP-17
> >> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+Add+support+for+PEM+based+key+material+for+SSL
> >.
> >> I think it would be a great addition to support a commonly used format
> for
> >> private keys and trusted certificates for SSL configurations.
> >>
> >> Thank you.
> >> Maulin
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

[DISCUSS] CEP-17: Add support for PEM based key material for SSL

[Maulin Vasavada]

Hi all,

I would like to start this discussion thread for the CEP-17
.
I think it would be a great addition to support a commonly used format for
private keys and trusted certificates for SSL configurations.

Thank you.
Maulin

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

Re: [VOTE] CIP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Yay! Thanks Benjamin and everybody who participated. Feeling fully
energized to finish the work!

On Fri, Jul 16, 2021 at 9:59 AM Benjamin Lerer  wrote:

> Vote passes with five binding +1, three non binding +1 and no vetos.
>
> Le mer. 14 juil. 2021 à 16:02, Joshua McKenzie  a
> écrit :
>
> > +1
> >
> > On Wed, Jul 14, 2021 at 7:03 AM Paulo Motta 
> > wrote:
> >
> > > +1
> > >
> > > Em qua., 14 de jul. de 2021 às 02:29, Sumanth Pasupuleti <
> > > sumanth.pasupuleti...@gmail.com> escreveu:
> > >
> > > > +1 non-binding
> > > >
> > > > On Tue, Jul 13, 2021 at 10:05 PM Berenguer Blasi <
> > > berenguerbl...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On 14/7/21 0:34, Nate McCall wrote:
> > > > > > +1
> > > > > >
> > > > > >
> > > > > > On Wed, Jul 14, 2021 at 2:49 AM Benjamin Lerer <
> ble...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > >> Hi everyone,
> > > > > >>
> > > > > >> I am proposing the CIP-9 (Make SSLContext creation pluggable)
> for
> > > > > adoption
> > > > > >>
> > > > > >> Discussion thread:
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/rbf99c0108a65f5e31a8f8f0ee525816ee0a387a6fae64de86ceb1495%40%3Cdev.cassandra.apache.org%3E
> > > > > >>
> > > > > >>
> > > > > >> The vote will be open for 72 hours.
> > > > > >> Votes by PMC members are considered binding. A
> > > > > >> vote passes if there are at least three binding +1s and no
> binding
> > > > > vetoes.
> > > > > >>
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

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
> >> <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 
> 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
> >> in

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
<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  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
> > > > <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 / trust

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
> <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 
> 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 
>> 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 s

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

[Maulin Vasavada]

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

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

[Maulin Vasavada]

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

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

[Maulin Vasavada]

[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 
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 
> 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 
>> 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 Implementati

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

[Maulin Vasavada]

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 
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 
> 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 
>> wrote:
>>
>>> Hi all
>>>
>>> I wanted to consolidate a couple of comments that started in JIRA/Wiki
>>> here to keep it in one place. I'll post different posts as replies for each
>>> comment.
>>>
>>> Thanks
>>> Maulin
>>>
>>> On Tue, Jun 29, 2021 at 1:07 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com> wrote:
>>>
>>>> ^^^ bumping up ^^^ this thread since people might have more time
>>>> reviewing post 4.0 work. Specifically for this
>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations>
>>>> section in the CEP, I have coded for one option (here
>>>> <https://github.com/maulin-vasavada/cassandra/commit/256ad30ecedbc50d66d8a039f8ca9e47074737ce>)
>>>> and now will do for another option very soon.
>>>>
>>>> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada <
>>>> maulin.vasav...@gmail.com> wrote:
>>>>
>>>>> Thank you Dinesh and everybody. Will keep calm and wait for the
>>>>> feedback. Meanwhile I am experimenting with v

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

[Maulin Vasavada]

[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 
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 
> wrote:
>
>> Hi all
>>
>> I wanted to consolidate a couple of comments that started in JIRA/Wiki
>> here to keep it in one place. I'll post different posts as replies for each
>> comment.
>>
>> Thanks
>> Maulin
>>
>> On Tue, Jun 29, 2021 at 1:07 PM Maulin Vasavada <
>> maulin.vasav...@gmail.com> wrote:
>>
>>> ^^^ bumping up ^^^ this thread since people might have more time
>>> reviewing post 4.0 work. Specifically for this
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations>
>>> section in the CEP, I have coded for one option (here
>>> <https://github.com/maulin-vasavada/cassandra/commit/256ad30ecedbc50d66d8a039f8ca9e47074737ce>)
>>> and now will do for another option very soon.
>>>
>>> On Wed, Jun 2, 2021 at 5:11 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com> wrote:
>>>
>>>> Thank you Dinesh and everybody. Will keep calm and wait for the
>>>> feedback. Meanwhile I am experimenting with various implementation options
>>>> for what I put as "will seek community's input
>>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations>"
>>>> on the CEP document and learning little bit more about the CircleCI.
>>>>
>>>> On Wed, Jun 2, 2021 at 4:08 PM Dinesh Joshi 
>>>> 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
>>&

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

[Maulin Vasavada]

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

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
> <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 
> 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 
>> 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
>>&g

Re: [DISCUSS] Clarifying the CEP process

[Maulin Vasavada]

Based on my experience I definitely like the process where everything that
needs to be discussed about CEP remains in DISCUSS thread.

Also I like the comment made above " The jira ticket and PR can be created
as a PoC to help explain and illustrate the CEP, but nothing more than
that.". Sometimes it is necessary to really try making code changes and
realize the potential design challenge OR pitfalls and PoC PRs really help
in getting better CEP outcomes.

I am not sure about JIRA ticket creation while CEP is in DISCUSS. In my
particular example of CEP-9 I just carried over a process from another
Apache project. I think JIRA can be raised once CEP gets Approved and
changes can be officially tracked as JIRA ticket.

Thanks
Maulin

On Thu, Jul 8, 2021 at 10:21 AM Scott Hirleman 
wrote:

> Or maybe someone _can_ comment on the JIRA but should also for sure put
> that same comment in the discussion thread? That way, it is at worst
> redundant and doesn't get lost as a comment on a JIRA many may not see?
>
> On Thu, Jul 8, 2021 at 3:32 AM Mick Semb Wever  wrote:
>
> > > I think that’s a bit extreme – …
> >
> >
> >
> > Yeah, that was kinda my intention. But my thinking was just about getting
> > us out of our habits of using JIRA. Of course I didn't mean any censure.
> > Once we have some precedence in place, common-sense should prevail.
> >
> >
> > Perhaps we should put together a cheat sheet for kinds of discussion and
> > > what venue to raise them in at different phases in a CEP lifecycle.
> >
> >
> >
> > Agree.
> >
>
>
> --
> Scott Hirleman
> scott.hirle...@gmail.com
>

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
<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 
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 
> 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.
>> >>

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

[Maulin Vasavada]

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 
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
&

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

[Maulin Vasavada]

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 
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 in the business of
>>> picking
>>> > >>>> implementation to support. It looks like this is your intention
>>> as well?
>>> > >>>>
>>> > >>>> Thanks again,
>>> > >>>> -Nate
>>> > >>>>
>>> > >>>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
>>> > >>>> maulin.vasav...@gmail.com>
>>> > >>>> wrote:
>>> > >>>>
>>> > >>>> > Hi all
>>> > >>>> >
>>> > >>>> > Starting a discussion thread for the CIP-9 -
>>> > >>>> >
>>> > >>>> >
>>> > >>>>
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > However, while writing the CIP two areas that came up in my mind
>>> > >>>> where I
>>> > >>>> > need to seek guidance apart from the other discussion that we
>>> would
>>> > >>>> have
>>> > >>>> > here,
>>> > >>>> >
>>> > >>>> > 1. Whether to consider
>>> SSLFactory#tlsInstanceProtocolSubstitution()
>>> > >>>> > <
>>> > >>>> >
>>> > >>>>
>>> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
>>> > >>>> > >
>>> > >>>> > for pluggability (noted this on the CIP as well)
>>> > >>>> >
>>> > >>>> > 2. For Test Plan, apart from Integration Test and local system
>>> test
>>> > >>>> what
>>> > >>>> > would be recommended?
>>> > >>>> >
>>> > >>>> > Thanks
>>> > >>>> > Maulin
>>> > >>>> >
>>> > >>>>
>>> > >>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>
>>>

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

[Maulin Vasavada]

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 
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 in the business of picking
>> > >>>> implementation to support. It looks like this is your intention as
>> well?
>> > >>>>
>> > >>>> Thanks again,
>> > >>>> -Nate
>> > >>>>
>> > >>>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
>> > >>>> maulin.vasav...@gmail.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>> > Hi all
>> > >>>> >
>> > >>>> > Starting a discussion thread for the CIP-9 -
>> > >>>> >
>> > >>>> >
>> > >>>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
>> > >>>> >
>> > >>>> >
>> > >>>> > However, while writing the CIP two areas that came up in my mind
>> > >>>> where I
>> > >>>> > need to seek guidance apart from the other discussion that we
>> would
>> > >>>> have
>> > >>>> > here,
>> > >>>> >
>> > >>>> > 1. Whether to consider
>> SSLFactory#tlsInstanceProtocolSubstitution()
>> > >>>> > <
>> > >>>> >
>> > >>>>
>> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
>> > >>>> > >
>> > >>>> > for pluggability (noted this on the CIP as well)
>> > >>>> >
>> > >>>> > 2. For Test Plan, apart from Integration Test and local system
>> test
>> > >>>> what
>> > >>>> > would be recommended?
>> > >>>> >
>> > >>>> > Thanks
>> > >>>> > Maulin
>> > >>>> >
>> > >>>>
>> > >>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>

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

[Maulin Vasavada]

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 in the business of picking
> > >>>> implementation to support. It looks like this is your intention as
> well?
> > >>>>
> > >>>> Thanks again,
> > >>>> -Nate
> > >>>>
> > >>>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
> > >>>> maulin.vasav...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>> > Hi all
> > >>>> >
> > >>>> > Starting a discussion thread for the CIP-9 -
> > >>>> >
> > >>>> >
> > >>>>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
> > >>>> >
> > >>>> >
> > >>>> > However, while writing the CIP two areas that came up in my mind
> > >>>> where I
> > >>>> > need to seek guidance apart from the other discussion that we
> would
> > >>>> have
> > >>>> > here,
> > >>>> >
> > >>>> > 1. Whether to consider
> SSLFactory#tlsInstanceProtocolSubstitution()
> > >>>> > <
> > >>>> >
> > >>>>
> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
> > >>>> > >
> > >>>> > for pluggability (noted this on the CIP as well)
> > >>>> >
> > >>>> > 2. For Test Plan, apart from Integration Test and local system
> test
> > >>>> what
> > >>>> > would be recommended?
> > >>>> >
> > >>>> > Thanks
> > >>>> > Maulin
> > >>>> >
> > >>>>
> > >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

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

[Maulin Vasavada]

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 
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 
> 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 in the business of picking
>>>> implementation to support. It looks like this is your intention as well?
>>>>
>>>> Thanks again,
>>>> -Nate
>>>>
>>>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
>>>> maulin.vasav...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi all
>>>> >
>>>> > Starting a discussion thread for the CIP-9 -
>>>> >
>>>> >
>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
>>>> >
>>>> >
>>>> > However, while writing the CIP two areas that came up in my mind
>>>> where I
>>>> > need to seek guidance apart from the other discussion that we would
>>>> have
>>>> > here,
>>>> >
>>>> > 1. Whether to consider SSLFactory#tlsInstanceProtocolSubstitution()
>>>> > <
>>>> >
>>>> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
>>>> > >
>>>> > for pluggability (noted this on the CIP as well)
>>>> >
>>>> > 2. For Test Plan, apart from Integration Test and local system test
>>>> what
>>>> > would be recommended?
>>>> >
>>>> > Thanks
>>>> > Maulin
>>>> >
>>>>
>>>

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

[Maulin Vasavada]

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 
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 in the business of picking
>>> implementation to support. It looks like this is your intention as well?
>>>
>>> Thanks again,
>>> -Nate
>>>
>>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
>>> maulin.vasav...@gmail.com>
>>> wrote:
>>>
>>> > Hi all
>>> >
>>> > Starting a discussion thread for the CIP-9 -
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
>>> >
>>> >
>>> > However, while writing the CIP two areas that came up in my mind where
>>> I
>>> > need to seek guidance apart from the other discussion that we would
>>> have
>>> > here,
>>> >
>>> > 1. Whether to consider SSLFactory#tlsInstanceProtocolSubstitution()
>>> > <
>>> >
>>> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
>>> > >
>>> > for pluggability (noted this on the CIP as well)
>>> >
>>> > 2. For Test Plan, apart from Integration Test and local system test
>>> what
>>> > would be recommended?
>>> >
>>> > Thanks
>>> > Maulin
>>> >
>>>
>>

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

[Maulin Vasavada]

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 
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 in the business of picking
>> implementation to support. It looks like this is your intention as well?
>>
>> Thanks again,
>> -Nate
>>
>> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
>> maulin.vasav...@gmail.com>
>> wrote:
>>
>> > Hi all
>> >
>> > Starting a discussion thread for the CIP-9 -
>> >
>> >
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
>> >
>> >
>> > However, while writing the CIP two areas that came up in my mind where I
>> > need to seek guidance apart from the other discussion that we would have
>> > here,
>> >
>> > 1. Whether to consider SSLFactory#tlsInstanceProtocolSubstitution()
>> > <
>> >
>> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
>> > >
>> > for pluggability (noted this on the CIP as well)
>> >
>> > 2. For Test Plan, apart from Integration Test and local system test what
>> > would be recommended?
>> >
>> > Thanks
>> > Maulin
>> >
>>
>

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

[Maulin Vasavada]

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 in the business of picking
> implementation to support. It looks like this is your intention as well?
>
> Thanks again,
> -Nate
>
> On Wed, May 19, 2021 at 12:05 PM Maulin Vasavada <
> maulin.vasav...@gmail.com>
> wrote:
>
> > Hi all
> >
> > Starting a discussion thread for the CIP-9 -
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable
> >
> >
> > However, while writing the CIP two areas that came up in my mind where I
> > need to seek guidance apart from the other discussion that we would have
> > here,
> >
> > 1. Whether to consider SSLFactory#tlsInstanceProtocolSubstitution()
> > <
> >
> https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/security/SSLFactory.java#L169
> > >
> > for pluggability (noted this on the CIP as well)
> >
> > 2. For Test Plan, apart from Integration Test and local system test what
> > would be recommended?
> >
> > Thanks
> > Maulin
> >
>

[DISCUSS] CIP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

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()

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

Requesting the permission to create a CIP

[Maulin Vasavada]

Hi all

Can I get the permission to create a CIP (this is based on the
recommendation from CASSANDRA-1 ticket)?

My username: maulin.vasavada
Email: maulin.vasav...@gmail.com

Thanks
Maulin

Re: [DISCUSS] CASSANDRA-16666 - Make SSLContext creation pluggable/extensible

[Maulin Vasavada]

Thanks Erick. I've formed my thoughts on the changes including hotReloading
functionality. I'll start working on the write-up for the CIP.

On Thu, May 13, 2021 at 2:26 AM Erick Ramirez 
wrote:

> Welcome, Maulin! And thanks for being part of the Cassandra community. 🍻
>
> On Thu, 13 May 2021 at 10:15, Maulin Vasavada 
> wrote:
>
> > Hi
> >
> > I just created the CASSANDRA-1 JIRA ticket. Please let me know if the
> > discussion around that should happen here or on the jira ticket.
> >
> > I've contributed to Apache Kafka in the past but they have a little
> > different process for certain contributions by following KIP route.
> >
> > Looking forward to making a valuable contribution to the Cassandra stack.
> >
> > Thanks
> > Maulin
> >
>

Re: [DISCUSS] CASSANDRA-16666 - Make SSLContext creation pluggable/extensible

[Maulin Vasavada]

Thanks Josh! Will start that soon.

On Wed, May 12, 2021 at 6:20 PM Joshua McKenzie 
wrote:

> Welcome Maulin!
>
> Normally we have a pretty laissez-faire attitude about smaller changes, but
> storage engine changes or things that expose interfaces we're going to be
> committed to long-term we want a little more formal conversation around.
>
> This seems pretty non-controversial to me with significant prior art, but
> I'd recommend you draft up a quick CEP (cassandra enhancement proposal) for
> it and ping this thread to get interested parties to collab / review.
>
> See:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>
> Looking forward to it.
>
> ~Josh
>
> On Wed, May 12, 2021 at 8:15 PM Maulin Vasavada  >
> wrote:
>
> > Hi
> >
> > I just created the CASSANDRA-1 JIRA ticket. Please let me know if the
> > discussion around that should happen here or on the jira ticket.
> >
> > I've contributed to Apache Kafka in the past but they have a little
> > different process for certain contributions by following KIP route.
> >
> > Looking forward to making a valuable contribution to the Cassandra stack.
> >
> > Thanks
> > Maulin
> >
>

[DISCUSS] CASSANDRA-16666 - Make SSLContext creation pluggable/extensible

[Maulin Vasavada]

Hi

I just created the CASSANDRA-1 JIRA ticket. Please let me know if the
discussion around that should happen here or on the jira ticket.

I've contributed to Apache Kafka in the past but they have a little
different process for certain contributions by following KIP route.

Looking forward to making a valuable contribution to the Cassandra stack.

Thanks
Maulin