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
