Re: [DISCUSS] CEP-50: Authentication Negotiation
Thanks Andy - My hope/expectation is this would significantly reduce the amount of friction involved when either implementing or migrating to a new authenticator. I suspect it will benefit more complex environments too, when a single authenticator isn't ideal for all clients. At this point, the stickiest bits I've run into have involved logic that switches on "the" authenticator class, because of the hardcoded dependency on a specific authn implementation, and working out how to sanely extend the logic once it's possible for a single node to be using different authenticators for different client sessions. Solvable but will take some refactoring and might also generate debate about what the right behaviors are in that scenario. An example is the RoleManager which currently creates additional role attributes if the Password Authenticator is in use ... which, now that you mention it, I wonder if that's already broken for the MutualTlsWithPasswordFallbackAuthenticator. Hmm. Anyway, thanks for the feedback -- Joel. On 7/3/2025 7:52 AM, Tolbert, Andy wrote: Hi Joel, +1 (nb), I think this is a really good idea and well fleshed our CEP! The capability to allow the server to support multiple authenticators would be very useful. CEP-34 added a 'MutualTlsWithPasswordFallbackAuthenticator' for simultaneously supporting both mTLS and Password authentication, primarily as a means to introduce mTLS auth without breaking password auth and also a possible gradual migration to mTLS, but this only works for combining these two particular authenticators, and also creates another authenticator to support. The migration to any new auth strategy would likely involve the need to simultaneously support an existing and new auth provider. I think the approach you describe is well described and should meet this need assuming users use a driver that supports it. In terms of the protocol, utilizing the capabilities of the existing OPTIONS, STARTUP and SUPPORTED messages to communicate what authenticators are supported/should be used is pretty clever as it shouldn't require a protocol version uprev, and hopefully wouldn't be too complicated for a driver to implement. Thanks, Andy On Mon, Jun 30, 2025 at 11:44 AM Joel Shepherd wrote: Erm ... and here's the CEP: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-50%3A+Authentication+Negotiation (Thanks for the heads up, Abe ...) -- Joel. On 6/30/2025 9:37 AM, Joel Shepherd wrote: > Hello - We would like to propose CEP-50: Authentication Negotiation > for adoption by the community: . > > This CEP proposes minor changes to the initial handshake protocol > (OPTIONS, SUPPORTED and STARTUP messages) to enable a client to inform > the node of the authenticators supported by the client, and changes in > the node's authentication-related areas to enable it to pick its > preferred authenticator for each client client connection. The CEP > explains why this approach is proposed, instead of implementing a > "negotiating authenticator". > > Authentication negotiation will make it easier and safer for > administrators to migrate clusters to stronger authentication > mechanisms (including switching on authentication for a cluster that > has been using "allow-all" authentication) without downtime, and to > support environments where different clients prefer different > authentication mechanisms (e.g., username and password for ad-hoc > cqlsh access, mutual TLS for programmatic access, etc.), without > having to pick a single "lowest common denominator" authenticator for > all. Additionally, the proposed changes are intended to be backwards > compatible for both clients and nodes. > > Thanks in advance for your time and feedback. Please keep the > discussion on this mailing list thread. > > Thanks! -- Joel. > > > >
[VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1 (2nd attempt)
Hey folks, I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release (2nd attempt). sha1: 722707e3df954a43c5aa708de8569fff38f1d5a7 git: https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative The Source release is available here (r77919): https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/ This is the second vote being called for this release after the previous vote was stopped due to a critical bug [1] that was found (it's fixed now). The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1's. Thanks, João [1] https://issues.apache.org/jira/browse/CASSGO-82
Re: [DISCUSS] CEP-50: Authentication Negotiation
Hi Joel, +1 (nb), I think this is a really good idea and well fleshed our CEP! The capability to allow the server to support multiple authenticators would be very useful. CEP-34 added a 'MutualTlsWithPasswordFallbackAuthenticator' for simultaneously supporting both mTLS and Password authentication, primarily as a means to introduce mTLS auth without breaking password auth and also a possible gradual migration to mTLS, but this only works for combining these two particular authenticators, and also creates another authenticator to support. The migration to any new auth strategy would likely involve the need to simultaneously support an existing and new auth provider. I think the approach you describe is well described and should meet this need assuming users use a driver that supports it. In terms of the protocol, utilizing the capabilities of the existing OPTIONS, STARTUP and SUPPORTED messages to communicate what authenticators are supported/should be used is pretty clever as it shouldn't require a protocol version uprev, and hopefully wouldn't be too complicated for a driver to implement. Thanks, Andy On Mon, Jun 30, 2025 at 11:44 AM Joel Shepherd wrote: > Erm ... and here's the CEP: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-50%3A+Authentication+Negotiation > > (Thanks for the heads up, Abe ...) > > -- Joel. > > On 6/30/2025 9:37 AM, Joel Shepherd wrote: > > Hello - We would like to propose CEP-50: Authentication Negotiation > > for adoption by the community: . > > > > This CEP proposes minor changes to the initial handshake protocol > > (OPTIONS, SUPPORTED and STARTUP messages) to enable a client to inform > > the node of the authenticators supported by the client, and changes in > > the node's authentication-related areas to enable it to pick its > > preferred authenticator for each client client connection. The CEP > > explains why this approach is proposed, instead of implementing a > > "negotiating authenticator". > > > > Authentication negotiation will make it easier and safer for > > administrators to migrate clusters to stronger authentication > > mechanisms (including switching on authentication for a cluster that > > has been using "allow-all" authentication) without downtime, and to > > support environments where different clients prefer different > > authentication mechanisms (e.g., username and password for ad-hoc > > cqlsh access, mutual TLS for programmatic access, etc.), without > > having to pick a single "lowest common denominator" authenticator for > > all. Additionally, the proposed changes are intended to be backwards > > compatible for both clients and nodes. > > > > Thanks in advance for your time and feedback. Please keep the > > discussion on this mailing list thread. > > > > Thanks! -- Joel. > > > > > > > > >
Re: [VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1
I found a critical bug [1] while doing some testing and writing documentation. Since we don't have enough votes yet and I already have a PR up to fix this bug it's better to stop the vote now and redo the release. [1] https://issues.apache.org/jira/browse/CASSGO-82 Štefan Miklošovič escreveu (quarta, 2/07/2025 à(s) 13:23): > +1 > > On Mon, Jun 30, 2025 at 2:02 PM João Reis wrote: > >> Hey folks, >> >> I’m proposing the Apache Cassandra GoCQL Driver 2.0.0-rc1 for release. >> >> sha1: a9bfe80d8e6fad320c0737c9484056e9de7bef74 >> git: >> https://github.com/apache/cassandra-gocql-driver/tree/v2.0.0-rc1-tentative >> >> The Source release is available here (r77835): >> >> https://dist.apache.org/repos/dist/dev/cassandra/cassandra-gocql-driver/2.0.0-rc1/ >> >> This is a major release of the driver that includes the module name >> change from "github.com/gocql/gocql" to " >> github.com/apache/cassandra-gocql-driver/v2". During the donation >> process it was decided that this name change should happen in a major >> release since it is a breaking change. >> >> There's no code changes planned between 2.0.0-rc1 and 2.0.0 GA but we are >> working on documentation to help users navigate all the changes that went >> into this release. We want to get this rc1 release out before GA so users >> can start testing it while we work on the documentation. >> >> Developers will include this driver in their projects by specifying a >> commit hash or tag in go.mod rather than via the inclusion of binary >> artifacts so we’ve avoided the creation of binary artifacts completely. To >> avoid any premature access to this release before the vote is complete >> we’ve temporarily used the tag “v2.0.0-rc1-tentative” to clearly indicate >> that this tag points to a tentative release. Once the vote passes this tag >> will be updated to “v2.0.0-rc1”. >> >> The vote will be open for 72 hours (longer if needed). Everyone who has >> tested the build is invited to vote. Votes by PMC members are considered >> binding. A vote passes if there are at least three binding +1s and no -1's. >> >> Thanks, >> João >> >>
[RESULT][VOTE] Release Apache Cassandra GoCQL Driver 2.0.0-rc1
The vote has not passed due to found critical bug [1] https://issues.apache.org/jira/browse/CASSGO-82
Re: [DISCUSS] CEP-48: First-Class Materialized View Support
I believe that, with careful design, we could make the row-level repair work using the index-based approach. However, regarding the CEP-proposed solution, I want to highlight that the entire repair job can be divided into two parts: 1. Inconsistency detection 2. Rebuilding the inconsistent ranges The second step could look like this: nodetool mv_rebuild --base_table_range --mv_ranges [, , ...] The base table range and MV ranges would come from the first step. But it’s also possible to run this rebuild directly—without detecting inconsistencies—if we already know that some nodes need repair. This means we don’t have to wait for the snapshot processing to start the repair. Snapshot-based detection works well when the cluster is generally healthy. Compared to the current rebuild, the proposed approach doesn’t require dropping the MV and rebuilding it from scratch across the entire cluster—which is a major blocker for production environments. That said, for the index-based approach, I still think it introduces additional load on both the write path and compaction. This increases the resource cost of using MVs. While it’s a nice feature to enable row-level MV repair, its implementation is complex. On the other hand, the original proposal’s rebuild strategy is more versatile and likely to perform better—especially when only a few nodes need repair. In contrast, large-scale row-level comparisons via the index-based approach could be prohibitively expensive. Just to clarify my intention here: this is not a complete 'no' to the index-based approach. However, for the initial version, I believe it's more prudent to avoid impacting the hot path. We can start with a simpler design that keeps the critical path untouched, and then iterate to make it more robust over time—much like how other features in Apache Cassandra have evolved. For example, 'full repair' came first, followed by 'incremental repair'; similarly, STCS was later complemented by LCS. This phased evolution allows us to balance safety, stability, and long-term capability. Given all this, I still prefer to move forward with the original proposal. It allows us to avoid paying the repair overhead most of the time. On Tue, Jun 24, 2025 at 3:25 PM Blake Eggleston wrote: > Those are both fair points. Once you start dealing with data loss though, > maintaining guarantees is often impossible, so I’m not sure that torn > writes or updated timestamps are dealbreakers, but I’m fine with tabling > option 2 for now and seeing if we can figure out something better. > > Regarding the assassin cells, if you wanted to avoid explicitly agreeing > on a value, you might be able to only issue them for repaired base data, > which has been implicitly agreed upon. > > I think that or something like it is worth exploring. The idea would be to > solve this issue as completely as anti-compaction would - but without > having to rewrite sstables. I’d be interested to hear any ideas you have > about how that might work. > > You basically need a mechanism to erase some piece of data that was > written before a given wall clock time - regardless of cell timestamp, and > without precluding future updates (in wall clock time) with earlier > timestamps. > > On Mon, Jun 23, 2025, at 4:28 PM, Runtian Liu wrote: > > In the second option, we use the repair timestamp to re-update any cell or > row we want to fix in the base table. This approach is problematic because > it alters the write time of user-supplied data. Although Cassandra does not > allow users to set timestamps for LWT writes, users may still rely on the > update time. A key limitation of this approach is that it cannot fix cases > where a view cell ends up in a future state while the base table remains > correct. I now understand your point that Cassandra cannot handle this > scenario today. However, as I mentioned earlier, the important distinction > is that when this issue occurs in the base table, we accept the "incorrect" > data as valid—but this is not acceptable for materialized views, since the > source of truth (the base table) still holds the correct data. > > On Mon, Jun 23, 2025 at 12:05 PM Blake Eggleston > wrote: > > > > Sorry, Blake—I was traveling last week and couldn’t reply to your email > sooner. > > No worries, I’ll be taking some time off soon as well. > > > I don’t think the first or second option is ideal. We should treat the > base table as the source of truth. Modifying it—or forcing an update on it, > even if it’s just a timestamp change—is not a good approach and won’t solve > all problems. > > I agree the first option probably isn’t the right way to go. Could you say > a bit more about why the second option is not a good approach and which > problems it won’t solve? > > On Sun, Jun 22, 2025, at 6:09 PM, Runtian Liu wrote: > > Sorry, Blake—I was traveling last week and couldn’t reply to your email > sooner. > > > First - we interpret view data with higher timestamps than the
