You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "张铎(Duo Zhang)" <pa...@gmail.com> on 2022/02/05 08:05:24 UTC
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
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 <ap...@apache.org> 于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) <pa...@gmail.com>
> 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) <pa...@gmail.com> 于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 <an...@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 <
> apurtell@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
> > >> >> <we...@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 <bu...@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.purtell@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 <bu...@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 <
> > >> >>> pankajkumar@apache.org>
> > >> >>>>> wrote:
> > >> >>>>>>>
> > >> >>>>>>> +1 for reload4j.
> > >> >>>>>>>
> > >> >>>>>>> Regards,
> > >> >>>>>>> Pankaj
> > >> >>>>>>>
> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > >> >> palomino219@gmail.com
> > >> >>>>
> > >> >>>>> wrote:
> > >> >>>>>>>>
> > >> >>>>>>>> Already filed HBASE-26691.
> > >> >>>>>>>>
> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > >> >> vjasani@apache.org>
> > >> >>>>>>> wrote:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> > >> >>>>>>>>> andrew.purtell@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 <
> > zhangduo@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
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Filed https://issues.apache.org/jira/browse/LOG4J2-3394 for the problem I
met.
张铎(Duo Zhang) <pa...@gmail.com> 于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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <pa...@gmail.com>
>>> 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) <pa...@gmail.com> 于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 <an...@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 <
>>> apurtell@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
>>> > >> >> <we...@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 <bu...@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.purtell@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 <bu...@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 <
>>> > >> >>> pankajkumar@apache.org>
>>> > >> >>>>> wrote:
>>> > >> >>>>>>>
>>> > >> >>>>>>> +1 for reload4j.
>>> > >> >>>>>>>
>>> > >> >>>>>>> Regards,
>>> > >> >>>>>>> Pankaj
>>> > >> >>>>>>>
>>> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
>>> > >> >> palomino219@gmail.com
>>> > >> >>>>
>>> > >> >>>>> wrote:
>>> > >> >>>>>>>>
>>> > >> >>>>>>>> Already filed HBASE-26691.
>>> > >> >>>>>>>>
>>> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
>>> > >> >> vjasani@apache.org>
>>> > >> >>>>>>> wrote:
>>> > >> >>>>>>>>>
>>> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
>>> > >> >>>>>>>>>>
>>> > >> >>>>>>>>>>
>>> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
>>> > >> >>>>>>>>> andrew.purtell@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 <
>>> > zhangduo@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
>>>
>>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Got it.
We could try it once log4j 2.17.2 is released.
Thanks Andrew for helping!
Andrew Purtell <an...@gmail.com> 于2022年2月15日周二 11:51写道：
> If eg 2.4.9 binaries could be replaced with 2.5.0 and configuration files
> won’t need updating, there is no concern.
>
> > On Feb 14, 2022, at 7:35 PM, 张铎 <pa...@gmail.com> wrote:
> >
> > The new file format is for log4j2, which has a different name,
> > log4j2.properties.
> >
> > When you have log4j.properties and log4j-1.2-api.jar on the classpath,
> the
> > log4j1 bridge will take charge and initialize the logging system based on
> > your log4j.properties. This is my point.
> >
> > So in general, if you still want to use log4j.properties file, just
> remove
> > the log4j2.properties. If you want to fully migrate to log4j2, then you
> > need to learn the new grammar and change the log4j2.properties.
> >
> > We should mention this in the upgrade section.
> >
> > Thanks.
> >
> > Andrew Purtell <ap...@apache.org>于2022年2月15日 周二10:52写道：
> >
> >>> In the new release version we will provide a new log4j2 format
> properties
> >> file
> >>
> >> How can we assume users have not changed their log4j properties file? I
> >> have done it quite often in production. I can't be the only one.
> >>
> >>> Even if users have provided their own version of log4j.properties, we
> >> have log4j-1.2-api, it will read the log4j.properties and initialize the
> >> logging system based on log4j1 properties file
> >>
> >> Pardon me, but based on the new properties file in this patch, that does
> >> not seem to be true.
> >>
> >> I the log4j.properties file we ship now, property names begin with
> 'log4j'.
> >> In the new example provided by the log4j2 upgrade patch, property names
> do
> >> not begin with 'log4j.' .
> >>
> >> Operational compatibility in minor releases means existing configuration
> >> files should work with no changes required.
> >> Now, maybe this is a special case, but I do not like the idea of
> breaking
> >> users with something dumb like dropping the 'log4j.' prefix from
> property
> >> names, if it renders existing properties based configuration
> nonfunctional.
> >> So can we bridge this? That is my point.
> >>
> >>
> >>> On Sat, Feb 12, 2022 at 10:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
> >>> wrote:
> >>>
> >>> Good news, another approach for implementing LOG4J2-3341 has been
> landed,
> >>> and this time it is OK for us to pass hbase.root.logger in. This means
> >> the
> >>> most blocker issue for backporting the log4j2 support to branch-2 is
> >> gone.
> >>> We could try it once 2.17.2 is out.
> >>>
> >>> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 09:39写道：
> >>>
> >>>> When I was looking at the PR I also noticed a potentially annoying and
> >>>> compatibility breaking problem with the properties file format. Is it
> >>>> really true that with log4j1 the properties begin with 'log4j.' and
> >> with
> >>>> log4j2 the 'log4j.' prefix is removed? If so user configured files
> >> won't
> >>> be
> >>>> compatible unless we can intercept the parse of the file and map the
> >> one
> >>> to
> >>>> the other, somehow. Pardon my ignorance if that would not be necessary
> >>> and
> >>>> there is actually a path to compatibility. Anyway I mention it because
> >> if
> >>>> it is an issue, for both of these issues, perhaps we can plug
> something
> >>> in
> >>>> rather than rely on the log4j community? It is just a thought...
> >>>>
> >>> I do not get the point here. You mean we could do a configuration file
> >>> translation? In the new release version we will provide a new log4j2
> >> format
> >>> properties file, and I guess for most users they do not need to modify
> >> this
> >>> file, just modify hbase-env.sh to control the level and appenders is
> >>> enough.
> >>> Even if users have provided their own version of log4j.properties, we
> >> have
> >>> log4j-1.2-api, it will read the log4j.properties and initialize the
> >> logging
> >>> system based on log4j1 properties file, unless you have implemented
> your
> >>> log4j1 appenders.
> >>>
> >>>>
> >>>> On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Yes, the current solution does not work, they do not want to do
> >>> variable
> >>>>> lookup before entering the format free configuration processing step.
> >>>>>
> >>>>> Will try to push the log4j community to give another solution.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
> >>>>>
> >>>>>> So it looks like LOG4J2-3341 is going to be reverted? Backport
> >> seems
> >>>>>> premature until this is resolved with the new solution.
> >>>>>>
> >>>>>> On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <
> >> apurtell@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Thank you for providing a PR, will review on Monday.
> >>>>>>>
> >>>>>>> On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <
> >>> palomino219@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
> >>>>> palomino219@gmail.com
> >>>>>>>
> >>>>>>>>>> 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) <pa...@gmail.com> 于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 <an...@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 <
> >>> zyork@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 <
> >>>>>>>>>> apurtell@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
> >>>>>>>>>>>>>>> <we...@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 <bu...@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.purtell@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 <
> >>>>>>>> busbey@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 <
> >>>>>>>>>>>>>>>> pankajkumar@apache.org>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> +1 for reload4j.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>>>>> Pankaj
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> >>>>>>>>>>>>>>> palomino219@gmail.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Already filed HBASE-26691.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Wei-Chiu Chuang <we...@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 <
> >>>>>>>>>>>>>>> vjasani@apache.org>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> +1 for Reload4J migration in active release
> >>>>> branches.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew
> >>> Purtell <
> >>>>>>>>>>>>>>>>>>>>>> andrew.purtell@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 <
> >>>>>>>>>>> zhangduo@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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <an...@gmail.com>.
If eg 2.4.9 binaries could be replaced with 2.5.0 and configuration files won’t need updating, there is no concern.
> On Feb 14, 2022, at 7:35 PM, 张铎 <pa...@gmail.com> wrote:
>
> The new file format is for log4j2, which has a different name,
> log4j2.properties.
>
> When you have log4j.properties and log4j-1.2-api.jar on the classpath, the
> log4j1 bridge will take charge and initialize the logging system based on
> your log4j.properties. This is my point.
>
> So in general, if you still want to use log4j.properties file, just remove
> the log4j2.properties. If you want to fully migrate to log4j2, then you
> need to learn the new grammar and change the log4j2.properties.
>
> We should mention this in the upgrade section.
>
> Thanks.
>
> Andrew Purtell <ap...@apache.org>于2022年2月15日 周二10:52写道：
>
>>> In the new release version we will provide a new log4j2 format properties
>> file
>>
>> How can we assume users have not changed their log4j properties file? I
>> have done it quite often in production. I can't be the only one.
>>
>>> Even if users have provided their own version of log4j.properties, we
>> have log4j-1.2-api, it will read the log4j.properties and initialize the
>> logging system based on log4j1 properties file
>>
>> Pardon me, but based on the new properties file in this patch, that does
>> not seem to be true.
>>
>> I the log4j.properties file we ship now, property names begin with 'log4j'.
>> In the new example provided by the log4j2 upgrade patch, property names do
>> not begin with 'log4j.' .
>>
>> Operational compatibility in minor releases means existing configuration
>> files should work with no changes required.
>> Now, maybe this is a special case, but I do not like the idea of breaking
>> users with something dumb like dropping the 'log4j.' prefix from property
>> names, if it renders existing properties based configuration nonfunctional.
>> So can we bridge this? That is my point.
>>
>>
>>> On Sat, Feb 12, 2022 at 10:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
>>> wrote:
>>>
>>> Good news, another approach for implementing LOG4J2-3341 has been landed,
>>> and this time it is OK for us to pass hbase.root.logger in. This means
>> the
>>> most blocker issue for backporting the log4j2 support to branch-2 is
>> gone.
>>> We could try it once 2.17.2 is out.
>>>
>>> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 09:39写道：
>>>
>>>> When I was looking at the PR I also noticed a potentially annoying and
>>>> compatibility breaking problem with the properties file format. Is it
>>>> really true that with log4j1 the properties begin with 'log4j.' and
>> with
>>>> log4j2 the 'log4j.' prefix is removed? If so user configured files
>> won't
>>> be
>>>> compatible unless we can intercept the parse of the file and map the
>> one
>>> to
>>>> the other, somehow. Pardon my ignorance if that would not be necessary
>>> and
>>>> there is actually a path to compatibility. Anyway I mention it because
>> if
>>>> it is an issue, for both of these issues, perhaps we can plug something
>>> in
>>>> rather than rely on the log4j community? It is just a thought...
>>>>
>>> I do not get the point here. You mean we could do a configuration file
>>> translation? In the new release version we will provide a new log4j2
>> format
>>> properties file, and I guess for most users they do not need to modify
>> this
>>> file, just modify hbase-env.sh to control the level and appenders is
>>> enough.
>>> Even if users have provided their own version of log4j.properties, we
>> have
>>> log4j-1.2-api, it will read the log4j.properties and initialize the
>> logging
>>> system based on log4j1 properties file, unless you have implemented your
>>> log4j1 appenders.
>>>
>>>>
>>>> On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com>
>>>> wrote:
>>>>
>>>>> Yes, the current solution does not work, they do not want to do
>>> variable
>>>>> lookup before entering the format free configuration processing step.
>>>>>
>>>>> Will try to push the log4j community to give another solution.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
>>>>>
>>>>>> So it looks like LOG4J2-3341 is going to be reverted? Backport
>> seems
>>>>>> premature until this is resolved with the new solution.
>>>>>>
>>>>>> On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <
>> apurtell@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you for providing a PR, will review on Monday.
>>>>>>>
>>>>>>> On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <
>>> palomino219@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
>>>>> palomino219@gmail.com
>>>>>>>
>>>>>>>>>> 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) <pa...@gmail.com> 于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 <an...@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 <
>>> zyork@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 <
>>>>>>>>>> apurtell@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
>>>>>>>>>>>>>>> <we...@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 <bu...@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.purtell@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 <
>>>>>>>> busbey@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 <
>>>>>>>>>>>>>>>> pankajkumar@apache.org>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +1 for reload4j.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Pankaj
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
>>>>>>>>>>>>>>> palomino219@gmail.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Already filed HBASE-26691.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Wei-Chiu Chuang <we...@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 <
>>>>>>>>>>>>>>> vjasani@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> +1 for Reload4J migration in active release
>>>>> branches.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew
>>> Purtell <
>>>>>>>>>>>>>>>>>>>>>> andrew.purtell@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 <
>>>>>>>>>>> zhangduo@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
The new file format is for log4j2, which has a different name,
log4j2.properties.
When you have log4j.properties and log4j-1.2-api.jar on the classpath, the
log4j1 bridge will take charge and initialize the logging system based on
your log4j.properties. This is my point.
So in general, if you still want to use log4j.properties file, just remove
the log4j2.properties. If you want to fully migrate to log4j2, then you
need to learn the new grammar and change the log4j2.properties.
We should mention this in the upgrade section.
Thanks.
Andrew Purtell <ap...@apache.org>于2022年2月15日 周二10:52写道：
> > In the new release version we will provide a new log4j2 format properties
> file
>
> How can we assume users have not changed their log4j properties file? I
> have done it quite often in production. I can't be the only one.
>
> > Even if users have provided their own version of log4j.properties, we
> have log4j-1.2-api, it will read the log4j.properties and initialize the
> logging system based on log4j1 properties file
>
> Pardon me, but based on the new properties file in this patch, that does
> not seem to be true.
>
> I the log4j.properties file we ship now, property names begin with 'log4j'.
> In the new example provided by the log4j2 upgrade patch, property names do
> not begin with 'log4j.' .
>
> Operational compatibility in minor releases means existing configuration
> files should work with no changes required.
> Now, maybe this is a special case, but I do not like the idea of breaking
> users with something dumb like dropping the 'log4j.' prefix from property
> names, if it renders existing properties based configuration nonfunctional.
> So can we bridge this? That is my point.
>
>
> On Sat, Feb 12, 2022 at 10:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > Good news, another approach for implementing LOG4J2-3341 has been landed,
> > and this time it is OK for us to pass hbase.root.logger in. This means
> the
> > most blocker issue for backporting the log4j2 support to branch-2 is
> gone.
> > We could try it once 2.17.2 is out.
> >
> > Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 09:39写道：
> >
> > > When I was looking at the PR I also noticed a potentially annoying and
> > > compatibility breaking problem with the properties file format. Is it
> > > really true that with log4j1 the properties begin with 'log4j.' and
> with
> > > log4j2 the 'log4j.' prefix is removed? If so user configured files
> won't
> > be
> > > compatible unless we can intercept the parse of the file and map the
> one
> > to
> > > the other, somehow. Pardon my ignorance if that would not be necessary
> > and
> > > there is actually a path to compatibility. Anyway I mention it because
> if
> > > it is an issue, for both of these issues, perhaps we can plug something
> > in
> > > rather than rely on the log4j community? It is just a thought...
> > >
> > I do not get the point here. You mean we could do a configuration file
> > translation? In the new release version we will provide a new log4j2
> format
> > properties file, and I guess for most users they do not need to modify
> this
> > file, just modify hbase-env.sh to control the level and appenders is
> > enough.
> > Even if users have provided their own version of log4j.properties, we
> have
> > log4j-1.2-api, it will read the log4j.properties and initialize the
> logging
> > system based on log4j1 properties file, unless you have implemented your
> > log4j1 appenders.
> >
> > >
> > > On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > >
> > > > Yes, the current solution does not work, they do not want to do
> > variable
> > > > lookup before entering the format free configuration processing step.
> > > >
> > > > Will try to push the log4j community to give another solution.
> > > >
> > > > Thanks.
> > > >
> > > > Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
> > > >
> > > > > So it looks like LOG4J2-3341 is going to be reverted? Backport
> seems
> > > > > premature until this is resolved with the new solution.
> > > > >
> > > > > On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <
> apurtell@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Thank you for providing a PR, will review on Monday.
> > > > > >
> > > > > > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <
> > palomino219@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
> > > > palomino219@gmail.com
> > > > > >
> > > > > >> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> > zyork@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 <
> > > > > >> >> apurtell@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
> > > > > >> >> > >> >> <we...@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 <bu...@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.purtell@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 <
> > > > > >> busbey@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 <
> > > > > >> >> > >> >>> pankajkumar@apache.org>
> > > > > >> >> > >> >>>>> wrote:
> > > > > >> >> > >> >>>>>>>
> > > > > >> >> > >> >>>>>>> +1 for reload4j.
> > > > > >> >> > >> >>>>>>>
> > > > > >> >> > >> >>>>>>> Regards,
> > > > > >> >> > >> >>>>>>> Pankaj
> > > > > >> >> > >> >>>>>>>
> > > > > >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > > > > >> >> > >> >> palomino219@gmail.com
> > > > > >> >> > >> >>>>
> > > > > >> >> > >> >>>>> wrote:
> > > > > >> >> > >> >>>>>>>>
> > > > > >> >> > >> >>>>>>>> Already filed HBASE-26691.
> > > > > >> >> > >> >>>>>>>>
> > > > > >> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > > > > >> >> > >> >> vjasani@apache.org>
> > > > > >> >> > >> >>>>>>> wrote:
> > > > > >> >> > >> >>>>>>>>>
> > > > > >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release
> > > > branches.
> > > > > >> >> > >> >>>>>>>>>>
> > > > > >> >> > >> >>>>>>>>>>
> > > > > >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew
> > Purtell <
> > > > > >> >> > >> >>>>>>>>> andrew.purtell@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 <
> > > > > >> >> > zhangduo@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
> > > > > >> >>
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
> > > > >
> > > >
> > >
> > >
> > > --
> > > 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
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <ap...@apache.org>.
> In the new release version we will provide a new log4j2 format properties
file
How can we assume users have not changed their log4j properties file? I
have done it quite often in production. I can't be the only one.
> Even if users have provided their own version of log4j.properties, we
have log4j-1.2-api, it will read the log4j.properties and initialize the
logging system based on log4j1 properties file
Pardon me, but based on the new properties file in this patch, that does
not seem to be true.
I the log4j.properties file we ship now, property names begin with 'log4j'.
In the new example provided by the log4j2 upgrade patch, property names do
not begin with 'log4j.' .
Operational compatibility in minor releases means existing configuration
files should work with no changes required.
Now, maybe this is a special case, but I do not like the idea of breaking
users with something dumb like dropping the 'log4j.' prefix from property
names, if it renders existing properties based configuration nonfunctional.
So can we bridge this? That is my point.
On Sat, Feb 12, 2022 at 10:30 PM 张铎(Duo Zhang) <pa...@gmail.com>
wrote:
> Good news, another approach for implementing LOG4J2-3341 has been landed,
> and this time it is OK for us to pass hbase.root.logger in. This means the
> most blocker issue for backporting the log4j2 support to branch-2 is gone.
> We could try it once 2.17.2 is out.
>
> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 09:39写道：
>
> > When I was looking at the PR I also noticed a potentially annoying and
> > compatibility breaking problem with the properties file format. Is it
> > really true that with log4j1 the properties begin with 'log4j.' and with
> > log4j2 the 'log4j.' prefix is removed? If so user configured files won't
> be
> > compatible unless we can intercept the parse of the file and map the one
> to
> > the other, somehow. Pardon my ignorance if that would not be necessary
> and
> > there is actually a path to compatibility. Anyway I mention it because if
> > it is an issue, for both of these issues, perhaps we can plug something
> in
> > rather than rely on the log4j community? It is just a thought...
> >
> I do not get the point here. You mean we could do a configuration file
> translation? In the new release version we will provide a new log4j2 format
> properties file, and I guess for most users they do not need to modify this
> file, just modify hbase-env.sh to control the level and appenders is
> enough.
> Even if users have provided their own version of log4j.properties, we have
> log4j-1.2-api, it will read the log4j.properties and initialize the logging
> system based on log4j1 properties file, unless you have implemented your
> log4j1 appenders.
>
> >
> > On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> > > Yes, the current solution does not work, they do not want to do
> variable
> > > lookup before entering the format free configuration processing step.
> > >
> > > Will try to push the log4j community to give another solution.
> > >
> > > Thanks.
> > >
> > > Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
> > >
> > > > So it looks like LOG4J2-3341 is going to be reverted? Backport seems
> > > > premature until this is resolved with the new solution.
> > > >
> > > > On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <ap...@apache.org>
> > > > wrote:
> > > >
> > > > > Thank you for providing a PR, will review on Monday.
> > > > >
> > > > > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <
> palomino219@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
> > > palomino219@gmail.com
> > > > >
> > > > >> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> zyork@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 <
> > > > >> >> apurtell@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
> > > > >> >> > >> >> <we...@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 <bu...@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.purtell@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 <
> > > > >> busbey@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 <
> > > > >> >> > >> >>> pankajkumar@apache.org>
> > > > >> >> > >> >>>>> wrote:
> > > > >> >> > >> >>>>>>>
> > > > >> >> > >> >>>>>>> +1 for reload4j.
> > > > >> >> > >> >>>>>>>
> > > > >> >> > >> >>>>>>> Regards,
> > > > >> >> > >> >>>>>>> Pankaj
> > > > >> >> > >> >>>>>>>
> > > > >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > > > >> >> > >> >> palomino219@gmail.com
> > > > >> >> > >> >>>>
> > > > >> >> > >> >>>>> wrote:
> > > > >> >> > >> >>>>>>>>
> > > > >> >> > >> >>>>>>>> Already filed HBASE-26691.
> > > > >> >> > >> >>>>>>>>
> > > > >> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > > > >> >> > >> >> vjasani@apache.org>
> > > > >> >> > >> >>>>>>> wrote:
> > > > >> >> > >> >>>>>>>>>
> > > > >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release
> > > branches.
> > > > >> >> > >> >>>>>>>>>>
> > > > >> >> > >> >>>>>>>>>>
> > > > >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew
> Purtell <
> > > > >> >> > >> >>>>>>>>> andrew.purtell@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 <
> > > > >> >> > zhangduo@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
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > >
> > >
> >
> >
> > --
> > 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
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Good news, another approach for implementing LOG4J2-3341 has been landed,
and this time it is OK for us to pass hbase.root.logger in. This means the
most blocker issue for backporting the log4j2 support to branch-2 is gone.
We could try it once 2.17.2 is out.
Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 09:39写道：
> When I was looking at the PR I also noticed a potentially annoying and
> compatibility breaking problem with the properties file format. Is it
> really true that with log4j1 the properties begin with 'log4j.' and with
> log4j2 the 'log4j.' prefix is removed? If so user configured files won't be
> compatible unless we can intercept the parse of the file and map the one to
> the other, somehow. Pardon my ignorance if that would not be necessary and
> there is actually a path to compatibility. Anyway I mention it because if
> it is an issue, for both of these issues, perhaps we can plug something in
> rather than rely on the log4j community? It is just a thought...
>
I do not get the point here. You mean we could do a configuration file
translation? In the new release version we will provide a new log4j2 format
properties file, and I guess for most users they do not need to modify this
file, just modify hbase-env.sh to control the level and appenders is enough.
Even if users have provided their own version of log4j.properties, we have
log4j-1.2-api, it will read the log4j.properties and initialize the logging
system based on log4j1 properties file, unless you have implemented your
log4j1 appenders.
>
> On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
> > Yes, the current solution does not work, they do not want to do variable
> > lookup before entering the format free configuration processing step.
> >
> > Will try to push the log4j community to give another solution.
> >
> > Thanks.
> >
> > Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
> >
> > > So it looks like LOG4J2-3341 is going to be reverted? Backport seems
> > > premature until this is resolved with the new solution.
> > >
> > > On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > Thank you for providing a PR, will review on Monday.
> > > >
> > > > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > > > wrote:
> > > >
> > > >> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
> > palomino219@gmail.com
> > > >
> > > >> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> > > >> >> apurtell@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
> > > >> >> > >> >> <we...@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 <bu...@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.purtell@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 <
> > > >> busbey@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 <
> > > >> >> > >> >>> pankajkumar@apache.org>
> > > >> >> > >> >>>>> wrote:
> > > >> >> > >> >>>>>>>
> > > >> >> > >> >>>>>>> +1 for reload4j.
> > > >> >> > >> >>>>>>>
> > > >> >> > >> >>>>>>> Regards,
> > > >> >> > >> >>>>>>> Pankaj
> > > >> >> > >> >>>>>>>
> > > >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > > >> >> > >> >> palomino219@gmail.com
> > > >> >> > >> >>>>
> > > >> >> > >> >>>>> wrote:
> > > >> >> > >> >>>>>>>>
> > > >> >> > >> >>>>>>>> Already filed HBASE-26691.
> > > >> >> > >> >>>>>>>>
> > > >> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > > >> >> > >> >> vjasani@apache.org>
> > > >> >> > >> >>>>>>> wrote:
> > > >> >> > >> >>>>>>>>>
> > > >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release
> > branches.
> > > >> >> > >> >>>>>>>>>>
> > > >> >> > >> >>>>>>>>>>
> > > >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> > > >> >> > >> >>>>>>>>> andrew.purtell@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 <
> > > >> >> > zhangduo@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
> > > >> >>
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > 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
> > >
> >
>
>
> --
> 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
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <ap...@apache.org>.
When I was looking at the PR I also noticed a potentially annoying and
compatibility breaking problem with the properties file format. Is it
really true that with log4j1 the properties begin with 'log4j.' and with
log4j2 the 'log4j.' prefix is removed? If so user configured files won't be
compatible unless we can intercept the parse of the file and map the one to
the other, somehow. Pardon my ignorance if that would not be necessary and
there is actually a path to compatibility. Anyway I mention it because if
it is an issue, for both of these issues, perhaps we can plug something in
rather than rely on the log4j community? It is just a thought...
On Mon, Feb 7, 2022 at 4:26 PM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> Yes, the current solution does not work, they do not want to do variable
> lookup before entering the format free configuration processing step.
>
> Will try to push the log4j community to give another solution.
>
> Thanks.
>
> Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
>
> > So it looks like LOG4J2-3341 is going to be reverted? Backport seems
> > premature until this is resolved with the new solution.
> >
> > On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > Thank you for providing a PR, will review on Monday.
> > >
> > > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > > wrote:
> > >
> > >> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <
> palomino219@gmail.com
> > >
> > >> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> > >> >> apurtell@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
> > >> >> > >> >> <we...@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 <bu...@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.purtell@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 <
> > >> busbey@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 <
> > >> >> > >> >>> pankajkumar@apache.org>
> > >> >> > >> >>>>> wrote:
> > >> >> > >> >>>>>>>
> > >> >> > >> >>>>>>> +1 for reload4j.
> > >> >> > >> >>>>>>>
> > >> >> > >> >>>>>>> Regards,
> > >> >> > >> >>>>>>> Pankaj
> > >> >> > >> >>>>>>>
> > >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > >> >> > >> >> palomino219@gmail.com
> > >> >> > >> >>>>
> > >> >> > >> >>>>> wrote:
> > >> >> > >> >>>>>>>>
> > >> >> > >> >>>>>>>> Already filed HBASE-26691.
> > >> >> > >> >>>>>>>>
> > >> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > >> >> > >> >> vjasani@apache.org>
> > >> >> > >> >>>>>>> wrote:
> > >> >> > >> >>>>>>>>>
> > >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release
> branches.
> > >> >> > >> >>>>>>>>>>
> > >> >> > >> >>>>>>>>>>
> > >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> > >> >> > >> >>>>>>>>> andrew.purtell@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 <
> > >> >> > zhangduo@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
> > >> >>
> > >> >
> > >>
> > >
> > >
> > > --
> > > 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
> >
>
--
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
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
Yes, the current solution does not work, they do not want to do variable
lookup before entering the format free configuration processing step.
Will try to push the log4j community to give another solution.
Thanks.
Andrew Purtell <ap...@apache.org> 于2022年2月8日周二 03:54写道：
> So it looks like LOG4J2-3341 is going to be reverted? Backport seems
> premature until this is resolved with the new solution.
>
> On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <ap...@apache.org>
> wrote:
>
> > Thank you for providing a PR, will review on Monday.
> >
> > On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <pa...@gmail.com>
> > wrote:
> >
> >> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <palomino219@gmail.com
> >
> >> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> >> >> apurtell@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
> >> >> > >> >> <we...@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 <bu...@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.purtell@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 <
> >> busbey@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 <
> >> >> > >> >>> pankajkumar@apache.org>
> >> >> > >> >>>>> wrote:
> >> >> > >> >>>>>>>
> >> >> > >> >>>>>>> +1 for reload4j.
> >> >> > >> >>>>>>>
> >> >> > >> >>>>>>> Regards,
> >> >> > >> >>>>>>> Pankaj
> >> >> > >> >>>>>>>
> >> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> >> >> > >> >> palomino219@gmail.com
> >> >> > >> >>>>
> >> >> > >> >>>>> wrote:
> >> >> > >> >>>>>>>>
> >> >> > >> >>>>>>>> Already filed HBASE-26691.
> >> >> > >> >>>>>>>>
> >> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> >> >> > >> >> vjasani@apache.org>
> >> >> > >> >>>>>>> wrote:
> >> >> > >> >>>>>>>>>
> >> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
> >> >> > >> >>>>>>>>>>
> >> >> > >> >>>>>>>>>>
> >> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> >> >> > >> >>>>>>>>> andrew.purtell@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 <
> >> >> > zhangduo@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
> >> >>
> >> >
> >>
> >
> >
> > --
> > 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
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <ap...@apache.org>.
So it looks like LOG4J2-3341 is going to be reverted? Backport seems
premature until this is resolved with the new solution.
On Sat, Feb 5, 2022 at 12:04 PM Andrew Purtell <ap...@apache.org> wrote:
> Thank you for providing a PR, will review on Monday.
>
> On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <pa...@gmail.com>
> wrote:
>
>> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <pa...@gmail.com>
>> >> 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) <pa...@gmail.com> 于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 <an...@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 <
>> >> apurtell@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
>> >> > >> >> <we...@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 <bu...@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.purtell@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 <
>> busbey@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 <
>> >> > >> >>> pankajkumar@apache.org>
>> >> > >> >>>>> wrote:
>> >> > >> >>>>>>>
>> >> > >> >>>>>>> +1 for reload4j.
>> >> > >> >>>>>>>
>> >> > >> >>>>>>> Regards,
>> >> > >> >>>>>>> Pankaj
>> >> > >> >>>>>>>
>> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
>> >> > >> >> palomino219@gmail.com
>> >> > >> >>>>
>> >> > >> >>>>> wrote:
>> >> > >> >>>>>>>>
>> >> > >> >>>>>>>> Already filed HBASE-26691.
>> >> > >> >>>>>>>>
>> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
>> >> > >> >> vjasani@apache.org>
>> >> > >> >>>>>>> wrote:
>> >> > >> >>>>>>>>>
>> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
>> >> > >> >>>>>>>>>>
>> >> > >> >>>>>>>>>>
>> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
>> >> > >> >>>>>>>>> andrew.purtell@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 <
>> >> > zhangduo@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
>> >>
>> >
>>
>
>
> --
> 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
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <ap...@apache.org>.
Thank you for providing a PR, will review on Monday.
On Sat, Feb 5, 2022 at 5:16 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> 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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <pa...@gmail.com>
> >> 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) <pa...@gmail.com> 于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 <an...@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 <
> >> apurtell@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
> >> > >> >> <we...@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 <bu...@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.purtell@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 <busbey@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 <
> >> > >> >>> pankajkumar@apache.org>
> >> > >> >>>>> wrote:
> >> > >> >>>>>>>
> >> > >> >>>>>>> +1 for reload4j.
> >> > >> >>>>>>>
> >> > >> >>>>>>> Regards,
> >> > >> >>>>>>> Pankaj
> >> > >> >>>>>>>
> >> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> >> > >> >> palomino219@gmail.com
> >> > >> >>>>
> >> > >> >>>>> wrote:
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Already filed HBASE-26691.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> >> > >> >> vjasani@apache.org>
> >> > >> >>>>>>> wrote:
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> >> > >> >>>>>>>>> andrew.purtell@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 <
> >> > zhangduo@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
> >>
> >
>
--
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
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
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) <pa...@gmail.com> 于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 <ap...@apache.org> 于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) <pa...@gmail.com>
>> 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) <pa...@gmail.com> 于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 <an...@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 <
>> apurtell@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
>> > >> >> <we...@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 <bu...@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.purtell@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 <bu...@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 <
>> > >> >>> pankajkumar@apache.org>
>> > >> >>>>> wrote:
>> > >> >>>>>>>
>> > >> >>>>>>> +1 for reload4j.
>> > >> >>>>>>>
>> > >> >>>>>>> Regards,
>> > >> >>>>>>> Pankaj
>> > >> >>>>>>>
>> > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
>> > >> >> palomino219@gmail.com
>> > >> >>>>
>> > >> >>>>> wrote:
>> > >> >>>>>>>>
>> > >> >>>>>>>> Already filed HBASE-26691.
>> > >> >>>>>>>>
>> > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
>> > >> >> vjasani@apache.org>
>> > >> >>>>>>> wrote:
>> > >> >>>>>>>>>
>> > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>>
>> > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
>> > >> >>>>>>>>> andrew.purtell@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 <
>> > zhangduo@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
>>
>
Re: [DISCUSS] Replace log4j with reload4j for branch-2.x
Posted by Andrew Purtell <ap...@apache.org>.
For log4j2 backport to branch-2 and branch-2.5, although we need to
continue to provide properties based configuration examples in the conf/
directory that ships in our tarballs, it would also be fine to provide
equivalent XML format configuration examples in conf/, and we could add a
release note that encourages users to consider migrating from the
properties format to the XML format. The migration would be optional. That
is important for usability in a minor release.
On Sat, Feb 5, 2022 at 12:05 AM 张铎(Duo Zhang) <pa...@gmail.com> wrote:
> 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 <ap...@apache.org> 于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) <pa...@gmail.com>
> > 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) <pa...@gmail.com> 于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 <an...@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 <
> > apurtell@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
> > > >> >> <we...@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 <bu...@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.purtell@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 <bu...@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 <
> > > >> >>> pankajkumar@apache.org>
> > > >> >>>>> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>> +1 for reload4j.
> > > >> >>>>>>>
> > > >> >>>>>>> Regards,
> > > >> >>>>>>> Pankaj
> > > >> >>>>>>>
> > > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > > >> >> palomino219@gmail.com
> > > >> >>>>
> > > >> >>>>> wrote:
> > > >> >>>>>>>>
> > > >> >>>>>>>> Already filed HBASE-26691.
> > > >> >>>>>>>>
> > > >> >>>>>>>> Wei-Chiu Chuang <we...@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 <
> > > >> >> vjasani@apache.org>
> > > >> >>>>>>> wrote:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> > > >> >>>>>>>>> andrew.purtell@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 <
> > > zhangduo@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
> >
>
--
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