Filed https://issues.apache.org/jira/browse/LOG4J2-3394 for the problem I met.
张铎(Duo Zhang) <[email protected]> 于2022年2月5日周六 21:15写道： > https://github.com/apache/hbase/pull/4096 > > The PR based on log4j 2.17.2-SNAPSHOT is ready. > > PTAL. > > Next I will build the tarball and test whether the logging works as > expected. > > 张铎(Duo Zhang) <[email protected]> 于2022年2月5日周六 16:05写道： > >> On the config file format, on master branch I switched to xml because >> most log4j2 related resources(for example, answers on stackoverflow...) are >> xml based. But LOG4J2-3341 can only work with properties based config file >> format so the plan is to change back to properties file. >> Of course you still need to tweak the config files, as the config names >> are not exactly the same, but if we have LOG4J2-3341 then I do not think >> our users need to tweak the scripts, this is good news at least. >> >> We have already tried our best to not introduce log4j dependencies to our >> downstream users so I think the current branch-2.5 is already >> 'incompatible' enough for our users as in the old time we were likely to >> pull in log4j and slf4j-log4j if they depend on hbase-testing-util. But for >> me, I do not think introducing log4j as a dependency is the correct way so >> I would like to include this and add a section in the release announcement >> to say this. >> >> In short, I'm +1 on switching to log4j2 on branch-2.5 and I will offer my >> help to land the changes. >> >> Thanks. >> >> Andrew Purtell <[email protected]> 于2022年2月1日周二 02:49写道： >> >>> That is good news. >>> WDYT about integrating this work into branch-2.5 / 2.5.0, and branch-2, >>> of >>> course. Is it compatible enough? Needing to update a properties file and >>> tweaks to launch scripts, if any, would be fine and can be handled in a >>> release note. Switching away from a properties based format to an XML >>> format would not (just as example). >>> >>> On Sun, Jan 30, 2022 at 4:57 AM 张铎(Duo Zhang) <[email protected]> >>> wrote: >>> >>> > 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) <[email protected]> 于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 <[email protected]> 于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 <[email protected]> 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 < >>> [email protected] >>> > > >>> > >> 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 >>> > >> >> <[email protected]> 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 <[email protected]>於 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 < >>> > >> >>> [email protected]> >>> > >> >>>> 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 <[email protected]> >>> > >> >> 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 < >>> > >> >>> [email protected]> >>> > >> >>>>> wrote: >>> > >> >>>>>>> >>> > >> >>>>>>> +1 for reload4j. >>> > >> >>>>>>> >>> > >> >>>>>>> Regards, >>> > >> >>>>>>> Pankaj >>> > >> >>>>>>> >>> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) < >>> > >> >> [email protected] >>> > >> >>>> >>> > >> >>>>> wrote: >>> > >> >>>>>>>> >>> > >> >>>>>>>> Already filed HBASE-26691. >>> > >> >>>>>>>> >>> > >> >>>>>>>> Wei-Chiu Chuang <[email protected]> 于2022年1月21日周五 >>> 16:53写道： >>> > >> >>>>>>>> >>> > >> >>>>>>>>> +1 I am doing the same in Hadoop. >>> > >> >>>>>>>>> >>> > >> >>>>>>>>> On Fri, Jan 21, 2022 at 4:51 PM Viraj Jasani < >>> > >> >> [email protected]> >>> > >> >>>>>>> wrote: >>> > >> >>>>>>>>> >>> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches. >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell < >>> > >> >>>>>>>>> [email protected]> >>> > >> >>>>>>>>>> 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 < >>> > [email protected] >>> > >> >>> >>> > >> >>>>>>>> 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 >>> > >> >> >>> > >> >>> > > >>> > >>> >>> >>> -- >>> 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 >>> >>
