> On 4 Jun 2021, at 03:44, Jonathan Koppenhofer <j...@koppedomain.com> wrote: > > +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?
+1, I would think so too. Shipping a brand new, non-experimental feature with a security hole like this feels counter to our goal of releases being prod ready in .0, so I'm +1 on including it in an rc/ga > 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. >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
