I think we should replace log4j:log4j* with ch.qos.reload4j:reload4j:1.2.18.3
in every relevant POM.
On Thu, Jan 27, 2022 at 5:45 PM Wei-Chiu Chuang
<weic...@cloudera.com.invalid> wrote:
> 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
> > > >>
> > >
> >
>
--
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
