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