+1 to this being a serious bug. As a large user, if we used internal passwords, this would completely prevent me from using Cassandra native audit log capabilities. Disabling DCL is not a great option, as DCL is probably the most needed auditable event.
If this is on by default (not sure of default settings) I also assume this would be classified as an immediate CVE... Right? I don't directly contribute, so I can't talk too much, but I can't see how 4.0.0 could go GA with this. On Thu, Jun 3, 2021, 7:24 PM Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > > I am on the side of "this sounds like a really bad bug" for the audit > pieces, maybe less so than FQL. Anyone using audit for real probably has > meaningful audit requirements, which means they're in an industry where > they get audited for security, which means logging passwords is a big deal. > > +1. Given we are shipping audit logging feature for the first time with > 4.0, it would be great if this rather low complex patch can be included in > the 4.0 RC and thereby ship a "complete feature". > > On Thu, Jun 3, 2021 at 4:04 PM Vinay Chella <vche...@netflix.com.invalid> > wrote: > > > > I think it can be argued that this is a pretty serious bug for a newly > > introduced feature, and qualifies for inclusion in an RC, but I don’t > > personally have a strong opinion on if this should happen. > > +1 > > > > > One more point - if we keep the workaround, that should be documented > > with > > > big red letters for the users. > > > > Yes, heavy +1, if we are not merging it. Another idea, if we are not > > merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,) > > queries in the default configuration (cassandra.yaml) exclude list to > avoid > > oops for operators, since that is the only query type that log passwords > in > > plain text and all other places they are not. > > > > > > Thanks, > > Vinay > > > > > > On Thu, Jun 3, 2021 at 3:58 PM bened...@apache.org <bened...@apache.org> > > wrote: > > > > > I think it can be argued that this is a pretty serious bug for a newly > > > introduced feature, and qualifies for inclusion in an RC, but I don’t > > > personally have a strong opinion on if this should happen. > > > > > > I can’t imagine how this would be an _exception_ for inclusion in 4.0.1 > > > though. > > > > > > From: Mick Semb Wever <m...@apache.org> > > > Date: Thursday, 3 June 2021 at 22:45 > > > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > > > Subject: Re: Obfuscation of passwords in audit loging, in or not in > 4.0? > > > Thanks for raising this Stefan. > > > > > > > > > > > > > While I humbly think this is 4.0-worthy, the process we have, as far > > > > as I know, is that there should be only critical fixes in 4.0 so I > > > > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0 > > > > still? > > > > > > > > > > > > > I believe the question here is whether this patch is worthy of an > > exception > > > to go to 4.0.x. (i.e. 4.0.1) > > > At this point in time all improvements would be by default slated for > 4.x > > > (i.e. 4.1) > > > > > > It does not qualify as a RC critical bug for 4.0.0. > > > > > > Looking at the patch it is simple, and one could almost consider it a > > > security fix on a new 4.0 feature, so I'd say it's a valid exception > for > > > 4.0.x. > > > Keen to hear what others think. And how we should go about requesting > > such > > > exceptions for non-bugs during each annual release cycle. > > > > > >
