Re: Missing link to KEYS files on download page
Hi, I would update the asc file (and KEYS file if needed) so that if any user tries to verify the release, it can be verified. Kind Regards, Justin
Re: [RESULT] [VOTE] Release Apache Cassandra 3.0.30
Hi, Correct as it didn't contain a +1 in it. Justin
Re: [DISCUSS] guardail for global schema modifcations - CASSANDRA-19556 in the context of CASSANDRA-17495
> Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I > think that the option 1) is still viable - we would drop CASSANDRA-17495 and > we would have CASSANDRA-19556 instead of that which would act as a global > on/off on all schema modifications however given that we go into beta2 I am > not sure if it is not just too late. I think this is the best solution for our end-users long term excepting how close we are to a 5.0 GA. That said, guardrails aren't exactly super invasive destabilizing new features, so if you could get this patch in before we GA'd, I'd personally support making an exception for it. We discussed a bit on the ticket; I fall in the ambivalent space of "I like modularity, except for when it's unnecessary complexity for a use-case or flexibility that users don't need", and not being sure whether operators would need different guardrails for functionality. Especially given security and roles. On Mon, May 6, 2024, at 7:51 AM, Štefan Miklošovič wrote: > Hi list, > > there is a question in CASSANDRA-19556 we would like to have more feedback on > in order to move forward. > > CASSANDRA-19556 wants to introduce two guardrails. One for forbidding / > allowing DCL statements - (Authentication|Authorization)Statement - and > another one > for DDL statements (all schema modifications). > > However, there is already a guardrail implemented by CASSANDRA-17495 which > prevents only modifications of schema on a table level so CASSANDRA-19556 > might be viewed as a superset of CASSANDRA-17495. > > I am not sure why we stopped with tables only in CASSANDRA-17495, this might > be extended to keyspaces too, any schema modification really. I think we have > three options here: > > 1) drop CASSANDRA-17495 and implement CASSANDRA-19556 which would cover _all_ > schema modifications, not just table-related ones > 2) keep CASSANDRA-17495 and implement CASSANDRA-19556 as is currently > proposed - that means that we would be able to forbid all schema > modifications by CASSANDRA-19556 but once schema modifications are allowed, > we might further forbid table modifications as implemented by CASSANDRA-17495. > 3) keep CASSANDRA-17495 but change the implementation of CASSANDRA-19556 in > such a way that it would be more granular. What I mean by the granularity is > that we would have separate guardrail for keyspace, for example. > > 2) is the least impactful approach but what I do not like is that, basically, > one guardrail (CASSANDRA-19556) would shadow CASSANDRA-17495. For example, if > the first one is disabled but the second one is enabled, we can modify > keyspaces but we can not modify tables. When the first one is enabled, we can > not modify tables even 17495 is not disabled which I find counterintuitive. > > The pros of 3) would be that it would be more granular, indeed, but, is that > even necessary? There are a lot of ddl statements, creation of triggers, > views, indices, functions, aggregates ... How are we going to categorize it? > Do we want to have a guardrail per logical schema component? Is that not an > overkill? Can you come up with a scenario when an operator wants to disable > keyspace modifications but they would enable table modifications? Or > disabling just index, materialized view or function creations / modifications > but e.g keyspace modifications would be possible? Is it not easier to have > one guardrail for all schema modifications? > > Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I > think that the option 1) is still viable - we would drop CASSANDRA-17495 and > we would have CASSANDRA-19556 instead of that which would act as a global > on/off on all schema modifications however given that we go into beta2 I am > not sure if it is not just too late. > > Thank you for your opinions in advance. > > Regards
Re: [VOTE] Release Apache Cassandra 4.1.5
+1 On Thu, May 2, 2024 at 11:36 AM Brandon Williams wrote: > > Proposing the test build of Cassandra 4.1.5 for release. > > sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a > Git: https://github.com/apache/cassandra/tree/4.1.5-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/4.1.5/ > > 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. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/4.1.5-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt
Re: [VOTE] Release Apache Cassandra 4.0.13
+1 Kind Regards, Brandon On Thu, May 2, 2024 at 10:16 AM Brandon Williams wrote: > > Proposing the test build of Cassandra 4.0.13 for release. > > sha1: a6fb3b76feb8467d314b116f937322e1989b42e1 > Git: https://github.com/apache/cassandra/tree/4.0.13-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/ > > 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. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt > > Kind Regards, > Brandon
Re: Missing link to KEYS files on download page
On Wed, 8 May 2024 at 02:33, Justin Mclean wrote: > Hi, > > The Cassandra download page [1] includes signature files, but you also > need to include a link to the KEYS files to verify these. Relevant ASF > policy is here [2]. > > Trying the verify the latest source release, it fails with this error: > gpg: assuming signed data in 'apache-cassandra-5.0-beta1-src.tar.gz' > gpg: Signature made Sat 2 Dec 00:13:44 2023 AEDT > gpg:using RSA key A4C465FEA0C552561A392A61E91335D77E3E87CB > gpg: BAD signature from "Michael Semb Wever " > [unknown] Thanks for catching this. The signature on the 5.0-beta1-src tarball is confirmed wrong. This problem doesn't exist on other source release artefacts, as far as I have checked. I'll fix the downloads page. Not sure what we do about 5.0-beta1-src. Below is the correct signature, which can be also verified against the staged artifact we voted on in svn history: https://dist.apache.org/repos/dist/!svn/bc/65840/dev/cassandra/5.0-beta1/ ➤ cat apache-cassandra-5.0-beta1-src.tar.gz.asc -BEGIN PGP SIGNATURE- iQIzBAABCgAdFiEEpMRl/qDFUlYaOSph6RM1134+h8sFAmY7SgkACgkQ6RM1134+ h8svDg//UnyVuxiGFfJEqYoi7JMT/korqnOPTiiouGZIlAJtnjVNAEvzUp8k407M 9RpQPSyUwM1NWlicGmE0w69+s2NOTKiIIGuDIiUTqWPzT48MTOfS7VFZxpkty9uD lHyXPc4F3JGezwPX+iMs/ABA2sykxIIQMI+UsQzLMc3470JM3UqPlO0F8Zlh6nA+ 0uee2vM0aFJpa6e7zOG5xLRSAoVhSO1RR0gXm40uowtMvMdxYOLrlmOeXx4EDcbP A4YAtc2SSUX07cu7HfSski7luSSStSLUXFl+0XUZ2RXjSUCcpxuea1pZ1PKH15vC wA2Tl1Ro6MezGDFEvNnC4tM4YUvVC/wtbSYFG+ep1lqAKoR0mYa+jVjWss6qI0sR sSlD3m6p/XKhWV0oTcSBNJ+bBawFFFhDqS/xIXtUQWf/mVfeDOt67662epaaqYmC m6oN+iUlBeree/lBi32cg6rMc8TgI7gKmQpHSe4pX0avJoCbyt7akCpIgO0RgmDC caSwY7CumrYQ36DB21xL8bripp0IVlC5hD0HRsQ2ODqmIgcf3t5w4/90aSMMQaby cyKFKfYAD+0GzH2ZZ5jCOpQcMMMu1lrXByNRahNBBM5TOnw+3xSsMGe3X0AY80As PWl9s+aTLajbcI9NZ97Xszb5RwfzCm7u3O+41dtmEUeKoCOj7o8= =Z4Ey -END PGP SIGNATURE-
