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