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