av9ash/GitBugs huggingface dataset:
Bug: Remove accessibility to system_auth.roles salted_hash for non-superusers
Status: Patch Available
Priority: Normal
Created: 11/Jul/24 15:52

Cassandra permits all users with SELECT on system_auth.roles to access contents of the salted_hash column. This column contains a bcrypt hash, which shouldn't be visible. This isn't a significant security risk at the current time, but is prone to [retrospective decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We should protect this column so passwords cannot be cracked in the future.

 

 
{code:java}
$ ./bin/cqlsh -u cassandra -p cassandra
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND PASSWORD='nonsuperuser';
cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
[cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
 role         | can_login | is_superuser | member_of | salted_hash
--------------+-----------+--------------+-----------+--------------------------------------------------------------
    cassandra |      True |         True |      null | $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
 nonsuperuser |      True |        False |      null | $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
(2 rows)
{code}
 

Patches available:

3.0: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30

3.11: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311

4.0: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40

4.1: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41

5.0: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50

trunk: https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk
Bug: Equality check for Paxos.Electorate should not depend on collection types
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Sep/24 09:05
Resolved: 01/Nov/24 19:10

In fixing CASSANDRA-19904 on trunk, it became apparent that the comparison of local and remote electorates in {{Paxos::verifyElectorate}} does not successfully identify instances which contain the same natural and pending replicas if they are created with different implementations of {{Collection<InetAddressAndPort>}}. This causes the gossip state to be unnecessarily included in replica responses during paxos rounds, in turn thir results in unnecessary work being performed on the coordinator. This affects 4.1 and 5.0 versions, so we should backport the relevant part of the CASSANDRA-19904 patch.
Bug: type system contains check for duration does not work for hidden types
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Sep/24 19:28
Resolved: 23/Oct/24 17:56

The function "org.apache.cassandra.db.marshal.AbstractType#referencesDuration” relies on type overriding for detecting if the type contains a duration, but the hidden types like Composite or DynamicComposite don’t override this… this means that we will be able to create a 2i index for these columns (unless we use SAI as it properly detects this)

{code}
CREATE TABLE "tbl" (
    "pk1" int,
    "with_duration" 'CompositeType(ListType(DurationType))',
    PRIMARY KEY ("pk1")
);
CREATE INDEX ON "tbl"("with_duration");
{code}

This is able to create the 2i index even though we shouldn’t be able to due to duration not being allowed in indexes.

We have a test method that is able to detect if a type exists in complex types:

{code}
AbstractTypeGenerators.contains(type, DurationType.instance);
{code}

Could leverage the same logic to avoid maintenance burden with inheritance
Bug: Explicitly set locale to Locale.US
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Sep/24 13:58
Resolved: 29/Oct/24 08:12

Fresh installation of Cassandra 5.0 fails to start with the following error:

{code:java}
ERROR [main] 2024-09-25 14:50:58,401 CassandraDaemon.java:900 - Exception encountered during startup
java.lang.ExceptionInInitializerError: null
    at org.apache.cassandra.service.CassandraDaemon.setupVirtualKeyspaces(CassandraDaemon.java:575)
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:286)
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:744)
    at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)
Caused by: org.apache.cassandra.exceptions.SyntaxException: Failed parsing CREATE TABLE: [CREATE TABLE streaming (  id timeuuid,
  follower boolean,
  operation text, 
  peers frozen<list<text>>,
  status text,
  progress_percentage float,
  last_updated_at timestamp,
  duration_millis bigint,
  failure_cause text,
  success_message text,

  bytes_to_receive bigint, 
  bytes_received bigint, 
  bytes_to_send bigint, 
  bytes_sent bigint, 
  files_to_receive bigint, 
  files_received bigint, 
  files_to_send bigint, 
  files_sent bigint, 

  status_ınıt_timestamp timestamp,
  status_start_timestamp timestamp,
  status_success_timestamp timestamp,
  status_faılure_timestamp timestamp,

PRIMARY KEY ((id)))] reason: SyntaxException line 21:9 no viable alternative at character 'ı'
    at org.apache.cassandra.cql3.CQLFragmentParser.parseAny(CQLFragmentParser.java:48)
    at org.apache.cassandra.cql3.statements.schema.CreateTableStatement.parse(CreateTableStatement.java:465)
    at org.apache.cassandra.db.virtual.StreamingVirtualTable.<init>(StreamingVirtualTable.java:37)
    at org.apache.cassandra.db.virtual.SystemViewsKeyspace.<init>(SystemViewsKeyspace.java:47)
    at org.apache.cassandra.db.virtual.SystemViewsKeyspace.<clinit>(SystemViewsKeyspace.java:26)
    ... 4 common frames omitted
{code}
 
So, I changed my system language, re-created and deleted locales (switched from {{tr_TR.UTF-8}} to {{{}en_US.UTF-8{}}}), and changed it from GNOME Settings too.

I use Ubuntu 24.02. In this error you see {{'ı'}} (a Turkish character, i but without dot) used and Java basically couldn't find an alternative for {{'ı'}} but the question is I just installed Cassandra. I didn't create this table. This is probably for Cassandra and created automatically (I haven't used Cassandra, this was about to be my first time but as you can see I got error).

Also, I tried other stable version 41x, same result. I completely removed {{/var/lib/cassandra}} and {{/var/log cassandra}} before install too.

My solution (I am currently trying to test): adding {{Locale.US}} to all {{{}toLowerCase(){}}}, {{toUpperCase()}} etc. Because my keyboard map affects it. I think we can fix this with this way.
Bug: Count performance regression in Cassandra 4.x
Status: Triage Needed
Priority: Normal
Created: 24/Sep/24 13:47

Cassandra 4 exhibit a severe drop of performance on count operations.

We created a reproduction workflow inserting a 100k rows of 10kb random string

After this data is inserted in a 3 nodes cluster at RF3 and queried at LQ, a count on said table takes
- circa 2s on 3.11
- consistently more than 10s on 4.0 and 4.1 (around 12 to 13s) - tested 4.0.10 and 4.1.5

Observation of same program/query against each environment:

3.11
{code:java}
# COUNT #
61a5bcb0-75ca-11ef-9cff-55d571fe1347
Row count:100000
Count timing with fetch 5000: 0:00:01.846531
Average row size: 10000.0{code}

4.1
{code:java}
# COUNT #
55d79f60-75cb-11ef-a8be-399c3e257132
Row count:100000
Count timing with fetch 5000: 0:00:13.408626
Average row size: 10000.0{code}
The UUID shown in the above output is the trace ID on execution of the query which is then exported from each cluster via the command below and provide the cassXXtrace.txt file
{noformat}
cqlsh -e show session [trace_id] | tee cassXXtrace.txt{noformat}

Attached cass311trace.txt and cass41trace.txt which show the associated events from above query.

Note the issue is way more prevalent in a 3 nodes cluster (I also have tested on docker in one node and it's less visible).

Attaching objcount.py which contains 2 functions to insert and read the data. The insert is pretty slow due to generating random junk 10k objects but allows to reproduce. Just comment out the gateway_insert function for it to trigger data insert.
{code:java}
    # gateway_insert(session, ks, tbl)
    gateway_query(session, ks, tbl, fetch){code}
Requires argparse and cassandra driver
To use, run the following command. Consider uncommenting l.40 and 41 for ks/table creation and l. 155 for insert workload
{code:java}
python3 ./objcount.py -i <ip> -k <ks> -t <table>{code}
Bug: Add extra compaction junit
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Aug/24 11:28
Resolved: 24/Oct/24 06:19

Working on a custom compaction strategy we have found there is no junit making sure compactions strategies account for this specific scenario:

A- IR sessions starts on N sstables
B- Just before the IR session completes and the N sstables get moved out of pending repair a compaction kicks in
C- As the IR session is finalizing the compaction task removes the N sstables and creates a new one that will obviously be pending repair.
D- The IR session finalizes, the original N sstables are gone, the compaction finishes and a new sstable pending repair is created
E- That new sstable is orphaned as A. No active IR session knows about it B. No compaction is going to ever touch it as long as it is pending repair. So it it’s just left behind forever.

This ticket will add such junit.
Bug: Accord should not block partition restricted Index queries
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Sep/24 17:11
Resolved: 21/Oct/24 16:31

Accord requires partitions as part of the tracking protocol, which limits the use of range queries as no partition is known.  There are valid use cases for partition restricted index queries, yet those appear to be range queries which causes Accord to block them.

Rather than checking the type of the query, we should check if it has the following

1) selects a partition
2) if in LET clause, returns at most 1 run

Partition restricted index queries fit this, so should be allowed in both LET and returning SELECT clauses

Below is a test showing this doesn’t work

{code}
CREATE TABLE keyspace_test_00."tbl" (
    "pk1" tinyint,
    "pk2" ascii,
    "ck" frozen<map<frozen<set<date>>, 'org.apache.cassandra.db.marshal.DynamicCompositeType(p=>org.apache.cassandra.db.marshal.ShortType,n=>org.apache.cassandra.db.marshal.Int32Type,c=>org.apache.cassandra.db.marshal.IntegerType)'>>,
    "s1" frozen<map<frozen<list<inet>>, 'org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.DecimalType)'>> static,
    "s2" set<vector<uuid, 2>> static,
    "v1" 'org.apache.cassandra.db.marshal.CompositeType(org.apache.cassandra.db.marshal.ListType(org.apache.cassandra.db.marshal.TimeUUIDType),org.apache.cassandra.db.marshal.TimeType)',
    "v2" frozen<list<'org.apache.cassandra.db.marshal.LexicalUUIDType'>>,
    PRIMARY KEY (("pk1", "pk2"), "ck")
) WITH CLUSTERING ORDER BY ("ck" ASC);

CREATE INDEX ON keyspace_test_00.”tbl”(v2) USING ’sai’;

BEGIN TRANSACTION
  SELECT *
  FROM keyspace_test_00."tbl"
  WHERE "v2" = ? AND "pk1" = (tinyint) ? - (tinyint) ? AND "pk2" = ?
  LIMIT 1;
COMMIT TRANSACTION;
{code}

Fails with

{code}
Caused by: org.apache.cassandra.exceptions.InvalidRequestException: Range queries are not allowed for reads within a transaction; returning select at [2:3]
	at org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:370)
	at org.apache.cassandra.cql3.statements.RequestValidations.checkTrue(RequestValidations.java:97)
	at org.apache.cassandra.cql3.statements.RequestValidations.checkFalse(RequestValidations.java:223)
	at org.apache.cassandra.cql3.statements.TransactionStatement$Parsed.checkAtMostOneRowSpecified(TransactionStatement.java:603)
	at org.apache.cassandra.cql3.statements.TransactionStatement$Parsed.prepare(TransactionStatement.java:558)
{code}
Bug: Test Failure: org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest.coordinatorIsBehindTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Aug/24 18:02
Resolved: 18/Oct/24 17:17

Seen on current trunk here:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2726/workflows/2d5c888b-d5b8-4f72-9fcb-9e7ae0887940/jobs/61316/tests

{code:java}
java.lang.RuntimeException: Unterminated thread detected node2_isolatedExecutor:1 in group isolatedExecutor
	at org.apache.cassandra.distributed.impl.AbstractCluster.lambda$checkForThreadLeaks$16(AbstractCluster.java:1141)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
	at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1621)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
	at org.apache.cassandra.distributed.impl.AbstractCluster.checkForThreadLeaks(AbstractCluster.java:1139)
	at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1104)
	at org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest.coordinatorIsBehindTest(ConsistentBootstrapTest.java:227)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Bug: Allow configuration parameters for IAuthorizer, INetworkAuthorizer, and IRoleManager
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Sep/24 17:06
Resolved: 09/Oct/24 12:02

The implementation of custom authentication / authorization can be achieved by implementing {{{}IAuthenticator{}}}, {{{}IAuthorizer{}}}, {{{}IRoleManager{}}}, and other interfaces and configured in {{{}cassandra.yaml{}}}.

{{IAuthenticator}} implementations, for instance, can additionally read extra configuration parameters via a map of strings defined in {{{}cassandra.yaml{}}}.

Examples of valid configurations are:
{code:java}
authenticator: com.example.auth.CustomAuthenticator{code}
or
{code:java}
authenticator:
  class_name : com.example.auth.CustomAuthenticator
  parameters :
    param1 : value1
    param2 : value2{code}
This enables a C* admin to conveniently define and parameterize it's own custom Authenticator directly in {{{}cassandra.yaml{}}}.

This parameterization is currently enabled for {{Authenticator}} and {{CIDRAuthorizer}} implementations only and is missing for {{{}Authorizer{}}}, {{{}RoleManager{}}}, and {{NetworkAuthorizer.}}

To enable a C* admin to set and parameterize custom authentication/authorization implementations we should enable parametrization of all {{{}Authorizer{}}}, {{{}RoleManager{}}}, and {{NetworkAuthorizer}} implementations. This can be achieved by instantiating all auth-related implementations via {{{}ParameterizedClass{}}}.

From an user point of view, configuring existent authenticators/authorizators will have no visible changes.
Bug: We should throw exception when commitlog 's DiskAccessMode is direct but direct io is not support
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Aug/24 02:37
Resolved: 16/Aug/24 07:14

Looking into the code below : 
{code:java}
private static DiskAccessMode resolveCommitLogWriteDiskAccessMode(DiskAccessMode providedDiskAccessMode)
    {
        boolean compressOrEncrypt = getCommitLogCompression() != null || (getEncryptionContext() != null && getEncryptionContext().isEnabled());
        boolean directIOSupported = false;
        try
        {
            directIOSupported = FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;
        }
        catch (RuntimeException e)
        {
            logger.warn("Unable to determine block size for commit log directory: {}", e.getMessage());
        }

        if (providedDiskAccessMode == DiskAccessMode.auto)
        {
            if (compressOrEncrypt)
                providedDiskAccessMode = DiskAccessMode.legacy;
            else
            {
                providedDiskAccessMode = directIOSupported && conf.disk_optimization_strategy == Config.DiskOptimizationStrategy.ssd ? DiskAccessMode.direct
                                                                                                                                     : DiskAccessMode.legacy;
            }
        }

        if (providedDiskAccessMode == DiskAccessMode.legacy)
        {
            providedDiskAccessMode = compressOrEncrypt ? DiskAccessMode.standard : DiskAccessMode.mmap;
        }

        return providedDiskAccessMode;
    }
{code}

We should throw exception when user set the DiskAccessMode to direct for commitlog but the directIOSupported return false after the judgement of "FileUtils.getBlockSize(new File(getCommitLogLocation())) > 0;" instead of waiting for the system to start and accepting reads and writes.
Bug: Partition-restricted index and queries that use strict replica filtering can use SinglePartitionReadCommand
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Sep/24 15:48
Resolved: 11/Oct/24 21:01

Index and filtering queries have historically always been treated as range reads. However, when they are restricted to a partition, there is no reason they cannot be handled like single-partition reads, flowing through {{StorageProxy#fetchRows()}}. The benefit of doing this is that we may be able to take advantage of digest reads. The caveat is that this may not be possible (or worthwhile) when, for instance, SAI queries do not use strict filtering. When strict filtering is not active, we may need to filter combined replica results at the coordinator even when there isn’t a digest mismatch. When there is a digest mismatch, replica filtering protection will kick in during the read repair process and safely resolve this.

tl;dr We can safely treat partition-restricted index/SAI/filtering queries as single-partition reads, but initially it may be safest to do this only when strict filtering is enabled.
Bug: Nodetool support to get and set the authenticator and authorizer
Status: Open
Priority: Normal
Created: 26/Sep/24 18:01

Add {{nodetool}} support in Apache Cassandra to dynamically get and set {{authorizer}} and {{authenticator}} configurations. Currently, changes require updating the config file and restarting Cassandra. The new commands will allow administrators to make updates on-the-fly without a server restart, improving flexibility.
Bug: Relation#toRestriction() may not handle ReversedType properly
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Sep/24 15:47
Resolved: 04/Oct/24 22:51

{{o.a.c.cql3.Relation#toRestriction()}} uses {{ClusterMetadata#type}} directly but this type can be {{ReverseType}}, which seems to bypass most of the checks. Checks like {{isMultiCell()}} can be hard to spot as clustering keys don't allow multi-cell, but then we do checks like:

{noformat}
checkFalse(column.type instanceof ListType, "Indexes on list entries (%s[index] = value) are not supported.", column.name);
{noformat}

If the column is reversed clustering then this check always returns {{false}}, even if it's a reverse list!
Bug: NodeTool gcstats should have JSON / YAML output option
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jul/24 16:40
Resolved: 02/Oct/24 18:57

*nodetool help gcstats* does not show a JSON option

 
{noformat}
nodetool [(-h <host> | --host <host>)] [(-p <port> | --port <port>)]
                [(-pp | --print-port)] [(-pw <password> | --password <password>)]
                [(-pwf <passwordFilePath> | --password-file <passwordFilePath>)]
                [(-u <username> | --username <username>)] gcstats
{noformat}
Bug: CI running intensive tests in non-large dtest-upgrade runs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Sep/24 14:55
Resolved: 30/Sep/24 20:11

The non-large dtest-upgrade* test targets in `.build/run-python-dtests.sh` were not specifying `--skip-resource-intensive-tests`.

This was resulting in those test targets including the intensive tests and running for longer than the one hour timeout (per split) in ci-cassandra.a.o , which results in builds aborting…

dtest-large-latest is also missing as an option, and in the pipeline.

ci-cassandra.a.o Cassandra-5.0 builds #301 – #314+ and Cassandra-trunk #1912 – #1920+
Bug: Changing cdc table property can cause schema disagreement
Status: Patch Available
Priority: Normal
Created: 24/Sep/24 09:05

In the cassandra.yaml file, there is a parameter named "cdc_enabled" which allows CDC to be enabled or disabled on each individual nodes.

It has been found that it can cause schema disagreement or discrepancy when an "ALTER TABLE ... WITH cdc=..." statement is ran against a node which has "cdc_enabled" set to "false" in a cluster in which nodes have mixed "true"/"false" values for the "cdc_enabled" settings.

The exact behaviour of the above is version-dependant.

On Cassandra 4.1.1, the cluster will end up in the schema disagreement state. A rolling restart will bring the schema back in sync, but the changes made to the `cdc` table property will be lost. 

On Cassandra 4.1.6, the cluster will not have visible schema disagreement in the "nodetool describecluster" command's output, but the "ALTER TABLE" statement only has cosmetic effect on the node it is run. The node with "cdc_enabled" set to "false" will show the "cdc" table property has changed, but this does not affect its behaviour in any way. At the same time, other nodes do not see that table property change at all. This is perhaps even worse than on 4.1.1, because the alter table statement is silently failing. 

On Casandra 5.0.0, the behaviour is the same as 4.1.6.

A shell script for reproducing the above described behaviours in Docker, and the outputs of it on both 4.1.1 and 4.1.6 and 5.0.0 are attached.

 

Edit on 25 Sep: added test result on 5.0.0
Bug: should show error when altering table with Non-frozen UDTs with nested non-frozen collections
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Sep/24 06:28
Resolved: 18/Sep/24 21:35

Cassandra version: 5.0.0 GA

Given this type
{code:java}
CREATE TYPE testType
    (
        userids SET<UUID>
    );
{code}
If I try to create this table
{code:java}
CREATE TABLE test
(
    id     INT PRIMARY KEY,
    myType testType
);
{code}
It shows an error: "Non-frozen UDTs with nested non-frozen collections are not supported"

But if I create the table without the type and then alter the table:
{code:java}
CREATE TABLE test
(
    id     INT PRIMARY KEY
);
alter TABLE test add myType testType;
{code}
It does not show that error, which it should.
-------
Also the output of `describe test;` shows that it successfully altered the table.