What's the plan for other repos? hbase-filesystem, hbase-connectors, hbase-operator-tools depends on log4j 1.x
Even hbase-thirdparty has transitive dependency on log4j 1.x On Tue, Jan 25, 2022 at 5:16 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > 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 > > >> > > >
