> 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. > > >
