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) <palomino...@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 <apurt...@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) <palomino...@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) <palomino...@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 <andrew.purt...@gmail.com> 于2022年1月25日周二 10:09写道：
> > > >
> > > >> Reload4J is a great option when we really should maintain fairly
> > strict
> > > >> compatibility (patch releases) and less so when not (minors,
> majors).
> > > >>
> > > >> We haven’t released 2.5.0 yet. My fault, mainly... It’s been
> lagging.
> > > >> Perhaps we could backport Duo’s work from 3.0.0-alpha into
> branch-2.5
> > /
> > > >> 2.5.0? This would be a minor release, so, while some operational
> > > >> compatibility breaks would be somewhat surprising, it could be more
> > > >> understandable.
> > > >>
> > > >> > On Jan 24, 2022, at 5:00 PM, Zach York <zy...@apache.org> wrote:
> > > >> >
> > > >> > +1 on the original discussion
> > > >> >
> > > >> > I think that all makes sense, we can't know whether one dependency
> > is
> > > >> more
> > > >> > vulnerable/going to be more work to maintain or not. However, I
> > think
> > > >> > perhaps the more interesting question is whether we should be okay
> > > with
> > > >> > using EOL dependencies in any active release line. CVEs happen...
> I
> > > >> think
> > > >> > it's important to be able to react quickly. By depending on any
> EOL
> > > >> code in
> > > >> > our active release lines, we severely limit our ability to quickly
> > > deal
> > > >> > with CVEs. I understand it's not always easy (the backwards
> > > >> incompatibility
> > > >> > of log4j2 and the properties files are good examples), but it's
> also
> > > >> been
> > > >> > 6+ years since log4j 1.x has become EOL.
> > > >> >
> > > >> >> On Fri, Jan 21, 2022 at 11:47 AM Andrew Purtell <
> > apurt...@apache.org
> > > >
> > > >> wrote:
> > > >> >>
> > > >> >> I will offer a guess as answer to the question originally
> proposed,
> > > >> which
> > > >> >> is, no the Logging PMC is not going to behave in a cooperative
> > manner
> > > >> to
> > > >> >> Reload4J. The best we can hope for, and I personally doubt it, is
> > > they
> > > >> will
> > > >> >> not be actively hostile. Decisions made by Apache PMC can
> > > >> unfortunately be
> > > >> >> made on the basis of years-long running arguments and personality
> > > >> >> conflicts, and Logging is unfortunately one of them. Just my
> > opinion.
> > > >> You
> > > >> >> won't change it. Fortunately that is neither here nor there. We
> > > aren't
> > > >> here
> > > >> >> to judge up front if Reload4J can respond adequately to
> > hypothetical
> > > >> future
> > > >> >> security issues. That is not knowable and remains to be seen. It
> > also
> > > >> >> remains to be seen if Log4J 2 is going to respond adequately to
> > > future
> > > >> >> security issues. Or Netty. Or Jersey. Or Jackson. Or any of our
> > other
> > > >> risky
> > > >> >> third party dependencies (as measured by having "interesting"
> > CVEs).
> > > >> What
> > > >> >> we can do is look at the current track record, which has been
> > > adequate
> > > >> so
> > > >> >> far.
> > > >> >>
> > > >> >>
> > > >> >> On Fri, Jan 21, 2022 at 11:35 AM Wei-Chiu Chuang
> > > >> >> <weic...@cloudera.com.invalid> wrote:
> > > >> >>
> > > >> >>> The reload4j is maintained by one of the Apache Logging PMC.
> And a
> > > >> >> release
> > > >> >>> was made to address the latest log4j 1.x CVEs announced only a
> day
> > > >> after.
> > > >> >>>
> > > >> >>> There is a thread in the private@logging that mentioned the
> “new”
> > > >> >> log4j1.x
> > > >> >>> CVEs were actually not new. They were announced years before for
> > 2.x
> > > >> >> which
> > > >> >>> happens to also impact 1.x. But because 1.x was considered EOL,
> > they
> > > >> >> didn’t
> > > >> >>> bother to mention 1.x were affected. It is only now that 1.x’s
> > > getting
> > > >> >>> interest that they did this.
> > > >> >>>
> > > >> >>> Sean Busbey <bus...@apache.org>於 2022年1月22日 週六，上午2:47寫道：
> > > >> >>>
> > > >> >>>> It's relevant to what kind of mitigation this is. The
> > effectiveness
> > > >> of
> > > >> >>>> reload4j to deal with "the critical CVEs of log4j 1" is limited
> > by
> > > >> how
> > > >> >>>> likely it is that they know about them.
> > > >> >>>>
> > > >> >>>> Otherwise at the next CVE we're back in the same place where
> > > >> downstream
> > > >> >>>> users aren't meaningfully more protected. And in that case
> > perhaps
> > > we
> > > >> >>> would
> > > >> >>>> do better for our users by e.g. putting more emphasis upgrading
> > > >> across
> > > >> >>> our
> > > >> >>>> releases or providing breaking changes to get the pain over
> with.
> > > >> >>>>
> > > >> >>>> On Fri, Jan 21, 2022 at 11:03 AM Andrew Purtell <
> > > >> >>> andrew.purt...@gmail.com>
> > > >> >>>> wrote:
> > > >> >>>>
> > > >> >>>>> That does not seem germane to this discussion. We don’t
> > > investigate
> > > >> >> and
> > > >> >>>>> attempt to manage the security reporting arrangement of any of
> > our
> > > >> >>> other
> > > >> >>>>> third party dependencies.
> > > >> >>>>>
> > > >> >>>>>> On Jan 21, 2022, at 7:59 AM, Sean Busbey <bus...@apache.org>
> > > >> >> wrote:
> > > >> >>>>>>
> > > >> >>>>>> Has anyone asked the ASF Logging PMC if they'll forward
> > security
> > > >> >>>> reports
> > > >> >>>>>> against log4j 1 to the reload4j project?
> > > >> >>>>>>
> > > >> >>>>>>> On Fri, Jan 21, 2022 at 3:33 AM Pankaj Kumar <
> > > >> >>> pankajku...@apache.org>
> > > >> >>>>> wrote:
> > > >> >>>>>>>
> > > >> >>>>>>> +1 for reload4j.
> > > >> >>>>>>>
> > > >> >>>>>>> Regards,
> > > >> >>>>>>> Pankaj
> > > >> >>>>>>>
> > > >> >>>>>>>> On Fri, Jan 21, 2022, 2:39 PM 张铎(Duo Zhang) <
> > > >> >> palomino...@gmail.com
> > > >> >>>>
> > > >> >>>>> wrote:
> > > >> >>>>>>>>
> > > >> >>>>>>>> Already filed HBASE-26691.
> > > >> >>>>>>>>
> > > >> >>>>>>>> Wei-Chiu Chuang <weic...@apache.org> 于2022年1月21日周五
> 16:53写道：
> > > >> >>>>>>>>
> > > >> >>>>>>>>> +1 I am doing the same in Hadoop.
> > > >> >>>>>>>>>
> > > >> >>>>>>>>> On Fri, Jan 21, 2022 at 4:51 PM Viraj Jasani <
> > > >> >> vjas...@apache.org>
> > > >> >>>>>>> wrote:
> > > >> >>>>>>>>>
> > > >> >>>>>>>>>> +1 for Reload4J migration in active release branches.
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>> On Fri, 21 Jan 2022 at 12:52 PM, Andrew Purtell <
> > > >> >>>>>>>>> andrew.purt...@gmail.com>
> > > >> >>>>>>>>>> wrote:
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>>> +1 for migrating to Reload4J. It is binary and
> > configuration
> > > >> >>>>>>>> compatible
> > > >> >>>>>>>>>>> with log4j 1 so meets our compatibility guidelines.
> > > >> >>>>>>>>>>>
> > > >> >>>>>>>>>>> If this is an agreeable plan I can make the changes in a
> > PR
> > > >> >> and
> > > >> >>> we
> > > >> >>>>>>>> can
> > > >> >>>>>>>>> do
> > > >> >>>>>>>>>>> a round of new releases.
> > > >> >>>>>>>>>>>
> > > >> >>>>>>>>>>>> On Jan 20, 2022, at 10:16 PM, Duo Zhang <
> > > zhang...@apache.org
> > > >> >>>
> > > >> >>>>>>>> wrote:
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> On master we have already migrated to log4j2, but for
> > all
> > > >> >>> other
> > > >> >>>>>>>>>> release
> > > >> >>>>>>>>>>>> lines we are still on log4j1.
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> Recently there are several new CVEs for log4j1, so I
> > think
> > > we
> > > >> >>>>>>>> should
> > > >> >>>>>>>>>> also
> > > >> >>>>>>>>>>>> address them for release lines other than master.
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> One possible solution is to also migrate log4j2 but use
> > > >> >> log4j12
> > > >> >>>>>>>>> bridge
> > > >> >>>>>>>>>> to
> > > >> >>>>>>>>>>>> maintain the compatibility, but we have already known
> > that
> > > >> >>>>>>> log4j12
> > > >> >>>>>>>>>> bridge
> > > >> >>>>>>>>>>>> can not work perfectly with hadoop, as hadoop has some
> > > >> >>> customized
> > > >> >>>>>>>>>> log4j1
> > > >> >>>>>>>>>>>> appender implementations, which inherit some log4j1
> > > appenders
> > > >> >>>>>>> which
> > > >> >>>>>>>>> are
> > > >> >>>>>>>>>>> not
> > > >> >>>>>>>>>>>> part of the log4j12 bridge.
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> Reload4j is a fork of the log4j1 and has fixed the
> > critical
> > > >> >>> CVEs,
> > > >> >>>>>>>> so
> > > >> >>>>>>>>> it
> > > >> >>>>>>>>>>> is
> > > >> >>>>>>>>>>>> less hurt to replace log4j with reload4j.
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> Suggestions are welcomed.
> > > >> >>>>>>>>>>>>
> > > >> >>>>>>>>>>>> Thanks. Regards
> > > >> >>>>>>>>>>>
> > > >> >>>>>>>>>>
> > > >> >>>>>>>>>
> > > >> >>>>>>>>
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Best regards,
> > > >> >> Andrew
> > > >> >>
> > > >> >> Unrest, ignorance distilled, nihilistic imbeciles -
> > > >> >> It's what we’ve earned
> > > >> >> Welcome, apocalypse, what’s taken you so long?
> > > >> >> Bring us the fitting end that we’ve been counting on
> > > >> >> - A23, Welcome, Apocalypse
> > > >> >>
> > > >>
> > > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Unrest, ignorance distilled, nihilistic imbeciles -
> > It's what we’ve earned
> > Welcome, apocalypse, what’s taken you so long?
> > Bring us the fitting end that we’ve been counting on
> > - A23, Welcome, Apocalypse
> >
>
--
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
