Good news, LOG4J2-3341 has been landed. It will be released in log4j 2.17.2.
Will start to test it soon. Thanks. 张铎(Duo Zhang) <palomino...@gmail.com> 于2022年1月25日周二 17:15写道： > I would prefer we have LOG4J2-3341 first before releasing any 2.x releases > with log4j2. I pinged the log4j community once but no response yet. Will > try to ping again soon. > > Andrew Purtell <andrew.purt...@gmail.com> 于2022年1月25日周二 10:09写道： > >> Reload4J is a great option when we really should maintain fairly strict >> compatibility (patch releases) and less so when not (minors, majors). >> >> We haven’t released 2.5.0 yet. My fault, mainly... It’s been lagging. >> Perhaps we could backport Duo’s work from 3.0.0-alpha into branch-2.5 / >> 2.5.0? This would be a minor release, so, while some operational >> compatibility breaks would be somewhat surprising, it could be more >> understandable. >> >> > On Jan 24, 2022, at 5:00 PM, Zach York <zy...@apache.org> wrote: >> > >> > +1 on the original discussion >> > >> > I think that all makes sense, we can't know whether one dependency is >> more >> > vulnerable/going to be more work to maintain or not. However, I think >> > perhaps the more interesting question is whether we should be okay with >> > using EOL dependencies in any active release line. CVEs happen... I >> think >> > it's important to be able to react quickly. By depending on any EOL >> code in >> > our active release lines, we severely limit our ability to quickly deal >> > with CVEs. I understand it's not always easy (the backwards >> incompatibility >> > of log4j2 and the properties files are good examples), but it's also >> been >> > 6+ years since log4j 1.x has become EOL. >> > >> >> On Fri, Jan 21, 2022 at 11:47 AM Andrew Purtell <apurt...@apache.org> >> wrote: >> >> >> >> I will offer a guess as answer to the question originally proposed, >> which >> >> is, no the Logging PMC is not going to behave in a cooperative manner >> to >> >> Reload4J. The best we can hope for, and I personally doubt it, is they >> will >> >> not be actively hostile. Decisions made by Apache PMC can >> unfortunately be >> >> made on the basis of years-long running arguments and personality >> >> conflicts, and Logging is unfortunately one of them. Just my opinion. >> You >> >> won't change it. Fortunately that is neither here nor there. We aren't >> here >> >> to judge up front if Reload4J can respond adequately to hypothetical >> future >> >> security issues. That is not knowable and remains to be seen. It also >> >> remains to be seen if Log4J 2 is going to respond adequately to future >> >> security issues. Or Netty. Or Jersey. Or Jackson. Or any of our other >> risky >> >> third party dependencies (as measured by having "interesting" CVEs). >> What >> >> we can do is look at the current track record, which has been adequate >> so >> >> far. >> >> >> >> >> >> On Fri, Jan 21, 2022 at 11:35 AM Wei-Chiu Chuang >> >> <weic...@cloudera.com.invalid> wrote: >> >> >> >>> The reload4j is maintained by one of the Apache Logging PMC. And a >> >> release >> >>> was made to address the latest log4j 1.x CVEs announced only a day >> after. >> >>> >> >>> There is a thread in the private@logging that mentioned the “new” >> >> log4j1.x >> >>> CVEs were actually not new. They were announced years before for 2.x >> >> which >> >>> happens to also impact 1.x. But because 1.x was considered EOL, they >> >> didn’t >> >>> bother to mention 1.x were affected. It is only now that 1.x’s getting >> >>> interest that they did this. >> >>> >> >>> Sean Busbey <bus...@apache.org>於 2022年1月22日 週六，上午2:47寫道： >> >>> >> >>>> It's relevant to what kind of mitigation this is. The effectiveness >> of >> >>>> reload4j to deal with "the critical CVEs of log4j 1" is limited by >> how >> >>>> likely it is that they know about them. >> >>>> >> >>>> Otherwise at the next CVE we're back in the same place where >> downstream >> >>>> users aren't meaningfully more protected. And in that case perhaps we >> >>> would >> >>>> do better for our users by e.g. putting more emphasis upgrading >> across >> >>> our >> >>>> releases or providing breaking changes to get the pain over with. >> >>>> >> >>>> On Fri, Jan 21, 2022 at 11:03 AM Andrew Purtell < >> >>> andrew.purt...@gmail.com> >> >>>> wrote: >> >>>> >> >>>>> That does not seem germane to this discussion. We don’t investigate >> >> and >> >>>>> attempt to manage the security reporting arrangement of any of our >> >>> other >> >>>>> third party dependencies. >> >>>>> >> >>>>>> On Jan 21, 2022, at 7:59 AM, Sean Busbey <bus...@apache.org> >> >> wrote: >> >>>>>> >> >>>>>> Has anyone asked the ASF Logging PMC if they'll forward security >> >>>> reports >> >>>>>> against log4j 1 to the reload4j project? >> >>>>>> >> >>>>>>> On Fri, Jan 21, 2022 at 3:33 AM Pankaj Kumar < >> >>> pankajku...@apache.org> >> >>>>> wrote: >> >>>>>>> >> >>>>>>> +1 for reload4j. >> >>>>>>> >> >>>>>>> Regards, >> >>>>>>> Pankaj >> >>>>>>> >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) < >> >> palomino...@gmail.com >> >>>> >> >>>>> wrote: >> >>>>>>>> >> >>>>>>>> Already filed HBASE-26691. >> >>>>>>>> >> >>>>>>>> Wei-Chiu Chuang <weic...@apache.org> 于2022年1月21日周五 16:53写道： >> >>>>>>>> >> >>>>>>>>> +1 I am doing the same in Hadoop. >> >>>>>>>>> >> >>>>>>>>> On Fri, Jan 21, 2022 at 4:51 PM Viraj Jasani < >> >> vjas...@apache.org> >> >>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> +1 for Reload4J migration in active release branches. >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell < >> >>>>>>>>> andrew.purt...@gmail.com> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> +1 for migrating to Reload4J. It is binary and configuration >> >>>>>>>> compatible >> >>>>>>>>>>> with log4j 1 so meets our compatibility guidelines. >> >>>>>>>>>>> >> >>>>>>>>>>> If this is an agreeable plan I can make the changes in a PR >> >> and >> >>> we >> >>>>>>>> can >> >>>>>>>>> do >> >>>>>>>>>>> a round of new releases. >> >>>>>>>>>>> >> >>>>>>>>>>>> On Jan 20, 2022, at 10:16 PM, Duo Zhang <zhang...@apache.org >> >>> >> >>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> On master we have already migrated to log4j2, but for all >> >>> other >> >>>>>>>>>> release >> >>>>>>>>>>>> lines we are still on log4j1. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Recently there are several new CVEs for log4j1, so I think we >> >>>>>>>> should >> >>>>>>>>>> also >> >>>>>>>>>>>> address them for release lines other than master. >> >>>>>>>>>>>> >> >>>>>>>>>>>> One possible solution is to also migrate log4j2 but use >> >> log4j12 >> >>>>>>>>> bridge >> >>>>>>>>>> to >> >>>>>>>>>>>> maintain the compatibility, but we have already known that >> >>>>>>> log4j12 >> >>>>>>>>>> bridge >> >>>>>>>>>>>> can not work perfectly with hadoop, as hadoop has some >> >>> customized >> >>>>>>>>>> log4j1 >> >>>>>>>>>>>> appender implementations, which inherit some log4j1 appenders >> >>>>>>> which >> >>>>>>>>> are >> >>>>>>>>>>> not >> >>>>>>>>>>>> part of the log4j12 bridge. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Reload4j is a fork of the log4j1 and has fixed the critical >> >>> CVEs, >> >>>>>>>> so >> >>>>>>>>> it >> >>>>>>>>>>> is >> >>>>>>>>>>>> less hurt to replace log4j with reload4j. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Suggestions are welcomed. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks. Regards >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> >> -- >> >> Best regards, >> >> Andrew >> >> >> >> Unrest, ignorance distilled, nihilistic imbeciles - >> >> It's what we’ve earned >> >> Welcome, apocalypse, what’s taken you so long? >> >> Bring us the fitting end that we’ve been counting on >> >> - A23, Welcome, Apocalypse >> >> >> >
