Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Yuki Morishita]

Thinking more about "CREATE ROLE" permission, if we can extend CREATE
ROLE/ALTER ROLE statements, it may look streamlined:

I don't have the good example, but something like:
```
CREATE ROLE dev WITH LOGIN = true AND IDENTITIES = {'spiffe://xxx'};
ALTER ROLE dev ADD IDENTITY 'xxx';
LIST ROLES;
```

This requires a role to identities table as well as the current identity to
role table though.

On Thu, Jun 29, 2023 at 12:34 PM Yuki Morishita  wrote:

> Hi Jyothsna,
>
> I think for the *initial* commit, the description looks fine to me.
> I'd like to see/contribute to the future improvement though:
>
> * ADD IDENTITY requires SUPERUSER, this means that the brand new cluster
> needs to start with PasswordAuthenticator/CassandraAuthorizer first, and
> then change to mTLS one.
> * For this, I'd really like to see Cassandra use password authn and
> authz by default.
> * Cassandra allows the user with "CREATE ROLE" permission to create
> roles without superuser privilege. Maybe it is natural to allow them to add
> identities also?
>
>
> On Thu, Jun 29, 2023 at 7:35 AM Jyothsna Konisa 
> wrote:
>
>> Hi Yuki,
>>
>> I have added cassandra docs for CQL syntax that we are adding and how to
>> get started with using mTLS authenticators along with the migration plan.
>> Please review it and let me know if it looks good.
>>
>> Thanks,
>> Jyothsna Konisa.
>>
>> On Wed, Jun 21, 2023 at 10:46 AM Jyothsna Konisa 
>> wrote:
>>
>>> Hi Yuki!
>>>
>>> Thanks for the questions.
>>>
>>> Here are the steps for the initial setup.
>>>
>>> 1. Since only super users can add/remove identities from the
>>> `identity_to_roles` table, operators should use that role to add authorized
>>> identities to the table. Note that the authenticator is not an mTLS
>>> authenticator yet.
>>> EX: ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO
>>> ROLE 'read_only_user'
>>>
>>> 2. Change authenticator configuration in cassandra.yaml to use mTLS
>>> authenticator
>>> EX: authenticator:
>>>   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
>>>   parameters :
>>> validator_class_name:
>>> org.apache.cassandra.auth.SpiffeCertificateValidator
>>> 3. Restart the cluster so that newly configured mTLS authenticator is
>>> used
>>>
>>> What will be the op's first step to set up the roles and identities?
>>> -> Yes, the op should set up roles & identities first.
>>>
>>> Is default cassandra / cassandra superuser login still required to set
>>> up other roles and identities?
>>> -> When transitioning from a password based to mTLS based
>>> authenticators, yes superuser login is required to add identities, as only
>>> super users can add them. However when a cluster is using mTLS based
>>> authenticator, the super user will be associated with some certificate
>>> identity and hence we don't need password based cassandra super user login.
>>>
>>> If initial cassandra super user login is required, does that mean super
>>> users and "cassandra '' superuser bypass mTLS check?
>>> -> No, while adding identities to the roles table in step1 the
>>> authenticator will not be an mTLS authenticator. Once the identities are
>>> added and the authenticator is configured, even super users have to go
>>> through an mTLS check during connection.
>>>
>>>
>>> Regarding migration
>>>
>>> I *think* you need to first use
>>> MutualTlsWithPasswordFallbackAuthenticator so the current roles can login
>>> with their password,
>>> and eventually the admin sets up identity and then can switch to mTLS
>>> auth.
>>> Is this the expected way for migration?
>>> -> Yes you can do that or else we can add identities with password based
>>> login and then change the authenticator to be mTLS authenticator.
>>>
>>> I think a thorough documentation for this new feature including new CQL
>>> syntax, setting up and migration would be greatly appreciated.
>>> -> I have added documentation for the authenticators, cqlsh commands in
>>> the Javadocs in the source code. Maybe I will add the setup process &
>>> migration process in the Javadocs, does this sound good?
>>>
>>> Thanks,
>>> Jyothsna Konisa.
>>>
>>> On Tue, Jun 20, 2023 at 11:33 PM Yuki Morishita 
>>> wrote:
>>>
 Hi Jyothsna,

 Thanks, sorry I have additional questions regarding set up and
 migration:

 * Initial set up

 Say, you are building the brand new cassandra cluster with

 authenticator:
   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
   parameters :
 validator_class_name:
 org.apache.cassandra.auth.SpiffeCertificateValidator

 What will be the op's first step to set up the roles and identities?
 Is default cassandra / cassandra super user login still required to set
 up other roles and identities?
 If initial cassandra super user login is required, does that mean super
 users and "cassandra" superuser bypass mTLS check?

 * Migration

 If you are currently using PasswordAuthenticator 

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Yuki Morishita]

Hi Jyothsna,

I think for the *initial* commit, the description looks fine to me.
I'd like to see/contribute to the future improvement though:

* ADD IDENTITY requires SUPERUSER, this means that the brand new cluster
needs to start with PasswordAuthenticator/CassandraAuthorizer first, and
then change to mTLS one.
* For this, I'd really like to see Cassandra use password authn and
authz by default.
* Cassandra allows the user with "CREATE ROLE" permission to create
roles without superuser privilege. Maybe it is natural to allow them to add
identities also?


On Thu, Jun 29, 2023 at 7:35 AM Jyothsna Konisa 
wrote:

> Hi Yuki,
>
> I have added cassandra docs for CQL syntax that we are adding and how to
> get started with using mTLS authenticators along with the migration plan.
> Please review it and let me know if it looks good.
>
> Thanks,
> Jyothsna Konisa.
>
> On Wed, Jun 21, 2023 at 10:46 AM Jyothsna Konisa 
> wrote:
>
>> Hi Yuki!
>>
>> Thanks for the questions.
>>
>> Here are the steps for the initial setup.
>>
>> 1. Since only super users can add/remove identities from the
>> `identity_to_roles` table, operators should use that role to add authorized
>> identities to the table. Note that the authenticator is not an mTLS
>> authenticator yet.
>> EX: ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO
>> ROLE 'read_only_user'
>>
>> 2. Change authenticator configuration in cassandra.yaml to use mTLS
>> authenticator
>> EX: authenticator:
>>   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
>>   parameters :
>> validator_class_name:
>> org.apache.cassandra.auth.SpiffeCertificateValidator
>> 3. Restart the cluster so that newly configured mTLS authenticator is used
>>
>> What will be the op's first step to set up the roles and identities?
>> -> Yes, the op should set up roles & identities first.
>>
>> Is default cassandra / cassandra superuser login still required to set up
>> other roles and identities?
>> -> When transitioning from a password based to mTLS based authenticators,
>> yes superuser login is required to add identities, as only super users can
>> add them. However when a cluster is using mTLS based authenticator, the
>> super user will be associated with some certificate identity and hence we
>> don't need password based cassandra super user login.
>>
>> If initial cassandra super user login is required, does that mean super
>> users and "cassandra '' superuser bypass mTLS check?
>> -> No, while adding identities to the roles table in step1 the
>> authenticator will not be an mTLS authenticator. Once the identities are
>> added and the authenticator is configured, even super users have to go
>> through an mTLS check during connection.
>>
>>
>> Regarding migration
>>
>> I *think* you need to first use
>> MutualTlsWithPasswordFallbackAuthenticator so the current roles can login
>> with their password,
>> and eventually the admin sets up identity and then can switch to mTLS
>> auth.
>> Is this the expected way for migration?
>> -> Yes you can do that or else we can add identities with password based
>> login and then change the authenticator to be mTLS authenticator.
>>
>> I think a thorough documentation for this new feature including new CQL
>> syntax, setting up and migration would be greatly appreciated.
>> -> I have added documentation for the authenticators, cqlsh commands in
>> the Javadocs in the source code. Maybe I will add the setup process &
>> migration process in the Javadocs, does this sound good?
>>
>> Thanks,
>> Jyothsna Konisa.
>>
>> On Tue, Jun 20, 2023 at 11:33 PM Yuki Morishita 
>> wrote:
>>
>>> Hi Jyothsna,
>>>
>>> Thanks, sorry I have additional questions regarding set up and migration:
>>>
>>> * Initial set up
>>>
>>> Say, you are building the brand new cassandra cluster with
>>>
>>> authenticator:
>>>   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
>>>   parameters :
>>> validator_class_name:
>>> org.apache.cassandra.auth.SpiffeCertificateValidator
>>>
>>> What will be the op's first step to set up the roles and identities?
>>> Is default cassandra / cassandra super user login still required to set
>>> up other roles and identities?
>>> If initial cassandra super user login is required, does that mean super
>>> users and "cassandra" superuser bypass mTLS check?
>>>
>>> * Migration
>>>
>>> If you are currently using PasswordAuthenticator and would like to
>>> migrate to mTLS authentication:
>>>
>>> I *think* you need to first use
>>> MutualTlsWithPasswordFallbackAuthenticator so the current roles can login
>>> with their password,
>>> and eventually the admin sets up identity and then can switch to mTLS
>>> auth.
>>> Is this the expected way for migration?
>>>
>>> I think a thorough documentation for this new feature including new CQL
>>> syntax, setting up and migration would be greatly appreciated.
>>>
>>>
>>> On Wed, Jun 21, 2023 at 4:13 AM Jyothsna Konisa 
>>> wrote:
>>>
 Hi Yuki,

 Sorry I missed 

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[C. Scott Andreas]

+1nbOn Jun 28, 2023, at 6:40 PM, Abe Ratnofsky  wrote:+1 (nb)On Jun 28, 2023, at 18:38, guo Maxwell  wrote:+1 Nate McCall 于2023年6月29日 周四上午9:25写道：+1 On Wed, Jun 28, 2023 at 5:17 AM Shailaja Koppu  wrote:Hi Team,(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to follow usual procedure).Please vote on CEP 33 - CIDR filtering authorizer https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.Thanks,Shailaja
-- you are the apple of my eye !

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Abe Ratnofsky]

+1 (nb)On Jun 28, 2023, at 18:38, guo Maxwell  wrote:+1 Nate McCall 于2023年6月29日 周四上午9:25写道：+1 On Wed, Jun 28, 2023 at 5:17 AM Shailaja Koppu  wrote:Hi Team,(Starting a new thread for VOTE instead of reusing the DISCUSS thread, to follow usual procedure).Please vote on CEP 33 - CIDR filtering authorizer https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.Thanks,Shailaja
-- you are the apple of my eye !

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[guo Maxwell]

+1

Nate McCall 于2023年6月29日 周四上午9:25写道：

> +1
>
> On Wed, Jun 28, 2023 at 5:17 AM Shailaja Koppu  wrote:
>
>> Hi Team,
>>
>> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to
>> follow usual procedure).
>>
>> Please vote on CEP 33 - CIDR filtering authorizer
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
>> 
>> .
>>
>> Thanks,
>> Shailaja
>>
> --
you are the apple of my eye !

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Nate McCall]

+1

On Wed, Jun 28, 2023 at 5:17 AM Shailaja Koppu  wrote:

> Hi Team,
>
> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to
> follow usual procedure).
>
> Please vote on CEP 33 - CIDR filtering authorizer
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
> 
> .
>
> Thanks,
> Shailaja
>

Re: CASSANDRA-18554 - mTLS based client and internode authenticators

[Jyothsna Konisa]

Hi Yuki,

I have added cassandra docs for CQL syntax that we are adding and how to
get started with using mTLS authenticators along with the migration plan.
Please review it and let me know if it looks good.

Thanks,
Jyothsna Konisa.

On Wed, Jun 21, 2023 at 10:46 AM Jyothsna Konisa 
wrote:

> Hi Yuki!
>
> Thanks for the questions.
>
> Here are the steps for the initial setup.
>
> 1. Since only super users can add/remove identities from the
> `identity_to_roles` table, operators should use that role to add authorized
> identities to the table. Note that the authenticator is not an mTLS
> authenticator yet.
> EX: ADD IDENTITY 'spiffe://testdomain.com/testIdentifier/testValue' TO
> ROLE 'read_only_user'
>
> 2. Change authenticator configuration in cassandra.yaml to use mTLS
> authenticator
> EX: authenticator:
>   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
>   parameters :
> validator_class_name:
> org.apache.cassandra.auth.SpiffeCertificateValidator
> 3. Restart the cluster so that newly configured mTLS authenticator is used
>
> What will be the op's first step to set up the roles and identities?
> -> Yes, the op should set up roles & identities first.
>
> Is default cassandra / cassandra superuser login still required to set up
> other roles and identities?
> -> When transitioning from a password based to mTLS based authenticators,
> yes superuser login is required to add identities, as only super users can
> add them. However when a cluster is using mTLS based authenticator, the
> super user will be associated with some certificate identity and hence we
> don't need password based cassandra super user login.
>
> If initial cassandra super user login is required, does that mean super
> users and "cassandra '' superuser bypass mTLS check?
> -> No, while adding identities to the roles table in step1 the
> authenticator will not be an mTLS authenticator. Once the identities are
> added and the authenticator is configured, even super users have to go
> through an mTLS check during connection.
>
>
> Regarding migration
>
> I *think* you need to first use MutualTlsWithPasswordFallbackAuthenticator
> so the current roles can login with their password,
> and eventually the admin sets up identity and then can switch to mTLS auth.
> Is this the expected way for migration?
> -> Yes you can do that or else we can add identities with password based
> login and then change the authenticator to be mTLS authenticator.
>
> I think a thorough documentation for this new feature including new CQL
> syntax, setting up and migration would be greatly appreciated.
> -> I have added documentation for the authenticators, cqlsh commands in
> the Javadocs in the source code. Maybe I will add the setup process &
> migration process in the Javadocs, does this sound good?
>
> Thanks,
> Jyothsna Konisa.
>
> On Tue, Jun 20, 2023 at 11:33 PM Yuki Morishita 
> wrote:
>
>> Hi Jyothsna,
>>
>> Thanks, sorry I have additional questions regarding set up and migration:
>>
>> * Initial set up
>>
>> Say, you are building the brand new cassandra cluster with
>>
>> authenticator:
>>   class_name :org.apache.cassandra.auth.MutualTlsAuthenticator
>>   parameters :
>> validator_class_name:
>> org.apache.cassandra.auth.SpiffeCertificateValidator
>>
>> What will be the op's first step to set up the roles and identities?
>> Is default cassandra / cassandra super user login still required to set
>> up other roles and identities?
>> If initial cassandra super user login is required, does that mean super
>> users and "cassandra" superuser bypass mTLS check?
>>
>> * Migration
>>
>> If you are currently using PasswordAuthenticator and would like to
>> migrate to mTLS authentication:
>>
>> I *think* you need to first use
>> MutualTlsWithPasswordFallbackAuthenticator so the current roles can login
>> with their password,
>> and eventually the admin sets up identity and then can switch to mTLS
>> auth.
>> Is this the expected way for migration?
>>
>> I think a thorough documentation for this new feature including new CQL
>> syntax, setting up and migration would be greatly appreciated.
>>
>>
>> On Wed, Jun 21, 2023 at 4:13 AM Jyothsna Konisa 
>> wrote:
>>
>>> Hi Yuki,
>>>
>>> Sorry I missed answering your other question in the above reply.
>>> Regarding checking what identities are associated with a given role, one
>>> can make a query to list identities for a given role to the table. Also
>>> note that, addition or removal of identities from the table can only be
>>> performed by the super user only. Not even read-write users can perform
>>> modifications to the table.
>>>
>>> Also, If others have no concerns regarding this patch, can we move
>>> forward with the merge? or do we need voting on this one?
>>>
>>> Thanks,
>>> Jyothsna Konisa.
>>>
>>>
>>> On Mon, Jun 19, 2023 at 4:00 PM Jyothsna Konisa 
>>> wrote:
>>>
 Hi Yuki,
 You are right regarding adding a custom validator. If one wants to
 implement a CN based validator, 

Final Reminder: Community Over Code call for presentations closing soon

[Rich Bowen]

[Note: You're receiving this email because you are subscribed to one or
more project dev@ mailing lists at the Apache Software Foundation.]

This is your final reminder that the Call for Presentations for
Community Over Code (formerly known as ApacheCon) is closing soon - on
Thursday, 13 July 2023 at 23:59:59 GMT.

https://communityovercode.org/call-for-presentations/

We are looking for talk proposals on all topics related to ASF projects
and open source software.

The event will be held in Halifax, Nova Scotia, Octiber 7th through
10th. More details about the event may be found on the event website at
https://communityovercode.org/

Rich, for the event planners

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Jeremy Hanna]

+1 (nb) will be great to get this into the project.

> On Jun 28, 2023, at 12:15 PM, Patrick McFadin  wrote:
> 
> +1
> 
> On Wed, Jun 28, 2023 at 3:42 AM Brandon Williams  > wrote:
>> +1
>> 
>> Kind Regards,
>> Brandon
>> 
>> 
>> On Tue, Jun 27, 2023 at 12:17 PM Shailaja Koppu > > wrote:
>> >
>> > Hi Team,
>> >
>> > (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to 
>> > follow usual procedure).
>> >
>> > Please vote on CEP 33 - CIDR filtering authorizer 
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.
>> >
>> > Thanks,
>> > Shailaja

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Patrick McFadin]

+1

On Wed, Jun 28, 2023 at 3:42 AM Brandon Williams  wrote:

> +1
>
> Kind Regards,
> Brandon
>
>
> On Tue, Jun 27, 2023 at 12:17 PM Shailaja Koppu  wrote:
> >
> > Hi Team,
> >
> > (Starting a new thread for VOTE instead of reusing the DISCUSS thread,
> to follow usual procedure).
> >
> > Please vote on CEP 33 - CIDR filtering authorizer
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
> .
> >
> > Thanks,
> > Shailaja
>

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

[Bowen Song via dev]

IMHO, anyone upgrading software between major versions should expect to 
see breaking changes. Introducing breaking or major changes is the whole 
point of bumping major version numbers.


Since the library upgrade need to happen sooner or later, I don't see 
any reason why it should not happen in the 5.0 release.



On 27/06/2023 19:21, Maxim Muzafarov wrote:

Hello everyone,


We use the Dropwizard Metrics 3.1.5 library, which provides a basic
set of classes to easily expose Cassandra internals to a user through
various interfaces (the most common being JMX). We want to upgrade
this library version in the next major release 5.0 up to the latest
stable 4.2.19 for the following reasons:
- the 3.x (and 4.0.x) Dropwizard Metrics library is no longer
supported, which means that if we face a critical CVE, we'll still
need to upgrade, so it's better to do it sooner and more calmly;
- as of 4.2.5 the library supports jdk11, jdk17, so we will be in-sync
[1] as well as having some of the compatibility fixes mentioned in the
related JIRA [2];
- there have been a few user-related requests [3][4] whose
applications collide with the old version of the library, we want to
help them;


The problem

The problem with simply upgrading is that the JmxReporter class of the
library has moved from the com.codahale.metrics package in the 3.x
release to the com.codahale.metrics.jmx package in the 4.x release.
This is a problem for applications/tools that rely on the cassandra
classpath (lib/jars) as after the upgrade they may be looking for the
JmxReporter class which has changed its location.

A good example of the problem that we (or a user) may face after the
upgrade is our tests and the cassandra-driver-core 3.1.1, which uses
the old 3.x version of the library in tests. Of course, in this case,
we can upgrade the cassandra driver up to 4.x [5][6] to fix the
problem, as the new driver uses a newer version of the library, but
that's another story I won't go into for now. I'm talking more about
visualising the problem a user might face after upgrading to 5.0 if
he/she rely on the cassandra classpath, but on the other hand, they
might not face this problem at all because, as I understand, they will
provide this library in their applications by themselves.


So, since Cassandra has a huge ecosystem and a variety of tools that I
can't even imagine, the main question here is:

Can we move forward with this change without breaking backwards
compatibility with any kind of tools that we have considering the
example above as the main case? Do you have any thoughts on this?

The changes are here:
https://github.com/apache/cassandra/pull/2238/files



[1] 
https://github.com/dropwizard/metrics/pull/2180/files#diff-5dbf1a803ecc13ff945a08ed3eb09149a83615e83f15320550af8e3a91976446R14
[2] https://issues.apache.org/jira/browse/CASSANDRA-14667
[3] https://github.com/dropwizard/metrics/issues/1581#issuecomment-628430870
[4] https://issues.apache.org/jira/browse/STORM-3204
[5] https://issues.apache.org/jira/browse/CASSANDRA-15750
[6] https://issues.apache.org/jira/browse/CASSANDRA-17231

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

[Josh McKenzie]

Reasons 1 and 2 (getting into CVE coverage pipeline proactively rather than 
reactively, JDK consistency) seem compelling enough to justify the upgrade on 
their own to me.

> This is a problem for applications/tools that rely on the cassandra
> classpath (lib/jars) as after the upgrade they may be looking for the
> JmxReporter class which has changed its location.
Yep; this is going to be painful:
https://github.com/dropwizard/metrics/issues/1581
https://github.com/dropwizard/metrics/issues/1306
https://github.com/micrometer-metrics/micrometer/issues/587
https://github.com/doanduyhai/Achilles/issues/353
https://github.com/dropwizard/dropwizard/issues/2285

> in this case,
> we can upgrade the cassandra driver up to 4.x [5][6] to fix the
> problem, as the new driver uses a newer version of the library, but
> that's another story I won't go into for now
It seems like driver upgrades would be the cleanest way through this (and 
that's saying something...). With the driver donation in CEP-8 that'd help our 
ability to synchronize these updates, but there's still going to be plenty of 
noise and pain from this change.

Doesn't mean it's not worth doing though.

On Tue, Jun 27, 2023, at 2:21 PM, Maxim Muzafarov wrote:
> Hello everyone,
> 
> 
> We use the Dropwizard Metrics 3.1.5 library, which provides a basic
> set of classes to easily expose Cassandra internals to a user through
> various interfaces (the most common being JMX). We want to upgrade
> this library version in the next major release 5.0 up to the latest
> stable 4.2.19 for the following reasons:
> - the 3.x (and 4.0.x) Dropwizard Metrics library is no longer
> supported, which means that if we face a critical CVE, we'll still
> need to upgrade, so it's better to do it sooner and more calmly;
> - as of 4.2.5 the library supports jdk11, jdk17, so we will be in-sync
> [1] as well as having some of the compatibility fixes mentioned in the
> related JIRA [2];
> - there have been a few user-related requests [3][4] whose
> applications collide with the old version of the library, we want to
> help them;
> 
> 
> The problem
> 
> The problem with simply upgrading is that the JmxReporter class of the
> library has moved from the com.codahale.metrics package in the 3.x
> release to the com.codahale.metrics.jmx package in the 4.x release.
> This is a problem for applications/tools that rely on the cassandra
> classpath (lib/jars) as after the upgrade they may be looking for the
> JmxReporter class which has changed its location.
> 
> A good example of the problem that we (or a user) may face after the
> upgrade is our tests and the cassandra-driver-core 3.1.1, which uses
> the old 3.x version of the library in tests. Of course, in this case,
> we can upgrade the cassandra driver up to 4.x [5][6] to fix the
> problem, as the new driver uses a newer version of the library, but
> that's another story I won't go into for now. I'm talking more about
> visualising the problem a user might face after upgrading to 5.0 if
> he/she rely on the cassandra classpath, but on the other hand, they
> might not face this problem at all because, as I understand, they will
> provide this library in their applications by themselves.
> 
> 
> So, since Cassandra has a huge ecosystem and a variety of tools that I
> can't even imagine, the main question here is:
> 
> Can we move forward with this change without breaking backwards
> compatibility with any kind of tools that we have considering the
> example above as the main case? Do you have any thoughts on this?
> 
> The changes are here:
> https://github.com/apache/cassandra/pull/2238/files
> 
> 
> 
> [1] 
> https://github.com/dropwizard/metrics/pull/2180/files#diff-5dbf1a803ecc13ff945a08ed3eb09149a83615e83f15320550af8e3a91976446R14
> [2] https://issues.apache.org/jira/browse/CASSANDRA-14667
> [3] https://github.com/dropwizard/metrics/issues/1581#issuecomment-628430870
> [4] https://issues.apache.org/jira/browse/STORM-3204
> [5] https://issues.apache.org/jira/browse/CASSANDRA-15750
> [6] https://issues.apache.org/jira/browse/CASSANDRA-17231
> 

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Brandon Williams]

+1

Kind Regards,
Brandon


On Tue, Jun 27, 2023 at 12:17 PM Shailaja Koppu  wrote:
>
> Hi Team,
>
> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to 
> follow usual procedure).
>
> Please vote on CEP 33 - CIDR filtering authorizer 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.
>
> Thanks,
> Shailaja