Hi, So our options are:
1. Ignore it. Most people aren't using this functionality. Most people aren't and shouldn't be exposing the logging port to untrusted networks But everyone loses at defense in depth (or is it breadth) if they use this functionality and someone might expose the port 2. Remove the offending classes from the 1.1.10 jar My crazy idea, break it, but only for the people using the vulnerable functionality. Possibly no one, but probably someone. Maybe they can upgrade it manually for their usage? This also has an issue when working with maven. 3. Upgrade it Definitely going to break some apps according to Michael Shuler. Happened when he tried it. Certainly we can upgrade in trunk? While we are at it come up to the latest version. Ariel On Tue, Feb 13, 2018, at 12:03 PM, Ariel Weisberg wrote: > Hi, > > I don't think the fix is in 1.1.11 looking at the diff between 1.1.11 > and 1.2.0 https://github.com/qos-ch/logback/compare/v_1.1.11...v_1.2.0 > > I looked at 1.1.11 and 1.1.10 and didn't see it there either. > > When you say stuff broke do you mean stuff not in the dtests or utests? > > Ariel > > On Tue, Feb 13, 2018, at 11:57 AM, Michael Shuler wrote: > > I tried a logback 1.2.x jar update a number of months ago to fix the > > broken log rotation (try setting rotation to a large number - you'll > > find you only get I think it was 10 files, regardless of setting). > > > > Like we've found updating other jars in the past, this seemingly > > "simple" update broke a number of application components, so we rolled > > it back and worked out another log rotation method. > > > > Looking at the logback changelog, I cannot tell if version 1.1.11 is > > fixed for this, or if that might be less breakage? There are a pretty > > significant number of API-looking changes from 1.1.3 to 1.2.3, so I do > > not wish to break other user's applications, as I have experienced. > > > > I do not think this should block the current releases, unless someone > > wants to do some significant testing and user outreach for tentatively > > breaking their applications. > > > > -- > > Michael > > > > On 02/13/2018 10:48 AM, Jason Brown wrote: > > > Ariel, > > > > > > If this is a legit CVE, then we would want to patch all the current > > > versions we support - which is 2.1 and higher. > > > > > > Also, is this worth stopping the current open vote for this patch? (Not in > > > a place to look at the patch and affects to impacted branches right now). > > > > > > Jason > > > > > > On Tue, Feb 13, 2018 at 08:43 Ariel Weisberg <ar...@weisberg.ws> wrote: > > > > > >> Hi, > > >> > > >> Seems like users could conceivably be using the vulnerable component. > > >> Also > > >> seems like like we need potentially need to do this as far back as 2.1? > > >> > > >> Anyone else have an opinion before I commit this? What version to start > > >> from? > > >> > > >> Ariel > > >> > > >> On Tue, Feb 13, 2018, at 5:59 AM, Thiago Veronezi wrote: > > >>> Hi dev team, > > >>> > > >>> Sorry to keep bothering you. > > >>> > > >>> This is just a friendly reminder that I would like to contribute to this > > >>> project starting with a fix for CASSANDRA-14183 > > >>> <https://issues.apache.org/jira/browse/CASSANDRA-14183>. > > >>> > > >>> []s, > > >>> Thiago. > > >>> > > >>> > > >>> > > >>> On Tue, Jan 30, 2018 at 8:05 AM, Thiago Veronezi <thi...@veronezi.org> > > >>> wrote: > > >>> > > >>>> Hi dev team, > > >>>> > > >>>> Can one of you guys take a look on this jira ticket? > > >>>> https://issues.apache.org/jira/browse/CASSANDRA-14183 > > >>>> > > >>>> It has an a patch available for a known security issue with one of the > > >>>> dependencies. It has only with trivial code changes. It should be > > >>>> straightforward to review it. Any feedback is very welcome. > > >>>> > > >>>> Thanks, > > >>>> Thiago > > >>>> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
