This is the thread in zookeeper dev mailing list for discussing whether to migrate to logback
https://lists.apache.org/thread/1ktv03wvqtfg22d13c1yo1lgnjv6xpkt AFAICT they haven't decided yet, a member in the community posted exactly what I want to say I think it would be a mistake to use the recently reported vulnerability as > a basis for migrating to logback. Any dependency can have a vulnerability, > and logback is not substantially different. No dependency is going to be > guaranteed vulnerability-free. Switching on that basis is a wild goose > chase. What is important is that people respond to vulnerabilities by > updating/patching in a timely manner. Also, it is my understanding that > log4j2 is the evolution of logback and slf4j, incorporating the original > enhancements that logback had made as a standard slf4j implementation and > incorporating them back into log4j code, as well as providing a lot of > additional very useful features and a huge amount of configuration > flexibility. Although logback is probably still suitable, log4j2 seems to > be much more active, and where the mainline development for Java logging is > happening. Moving to logback from log4j2 seems like a step backwards. Most > importantly, though, the actual runtime logging implementation should be > independent from ZooKeeper project development. This project should use > slf4j as a logging facade exclusively, and users should be able to use > whatever slf4j runtime implementation they want. If ZooKeeper wants to > choose a simple implementation, it shouldn't use logback, but should use > slf4j-simple instead. However, I think it makes more sense to keep log4j2 > at runtime for the slf4j implementation. Users can still change it out for > whatever they want. There's no need to take action to replace the runtime > implementation for slf4j, because users can do that if they want... as long > as the project itself limits its logging to using the slf4j API. > > And I checked the mailing list for several other projects which have already migrated to log4j2, such as fink and hive, there is no related topic about whether to switch from log4j2 to other logging frameworks, and I also did a search of logback, no result. And I also checked kafka, they are still actively working on migrating to log4j2 from log4j1. Anyway, since the work on migrating log4j2 is already done in hbase 3, if you think log4j2 is not suitable, please open a separated discussion thread to discuss this. Let's see the opinions from other folks in the community. Maybe we could make HBase itself 'log framework free', i.e, end users are free to use any log framework. Thanks. Andrew Purtell <apurt...@apache.org> 于2021年12月22日周三 06:11写道： > Although this isn't really the right place I did want to circle back here > because in this context we are discussing HBase 3 and voting on alpha > versions toward a GA version. > > ZooKeeper has decided to migrate from log4j to logback. Perhaps there would > be interest in doing that here, before 3.0 is finalized. > > On Sat, Dec 18, 2021 at 9:46 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > I think we are on the same page that we should upgrade to the newest > log4j2 > > version since the final release has not been published yet. > > > > But on log4j1, in our community we have discussed this before when there > is > > a CVE for it. You can view this page > > > > https://logging.apache.org/log4j/1.2/ > > > > And even for the recent CVE, log4j1 is also affected, as listed on the > page > > you provided. > > > > Log4j 1.x mitigation > > > > Log4j 1.x does not have Lookups so the risk is lower. Applications using > > Log4j 1.x are only vulnerable to this attack when they use JNDI in their > > configuration. A separate CVE (CVE-2021-4104) has been filed for this > > vulnerability. To mitigate: Audit your logging configuration to ensure it > > has no JMSAppender configured. Log4j 1.x configurations without > JMSAppender > > are not impacted by this vulnerability. > > > > It is as you said in the first paragraph, log4j1 has a special CVE for > it, > > and it will never be fixed. We need to say that ‘yes it is affected but > > only if you bla bla’, not good for end users right? > > > > So I still stand my point that, stay on log4j1 is not a good choice, it > is > > not because we have already done the work, it is our duty to keep our > users > > safe from security problem. > > > > And on the Hadoop part, it is also me that trying to upgrade to log4j2. > But > > as you know Hadoop is actually constructed by several projects, it is > > really not easy to do this work, like what we have done in HBase. > > > > Anyway, let me prepare a new RC. > > > > Thanks. > > Andrew Purtell <andrew.purt...@gmail.com>于2021年12月19日 周日09:12写道： > > > > > As to your first point, I think it is a simple consideration: A user’s > > > security department or compliance regulator will ask: “Does this > version > > > include log4j with a known CVE?” Why would we provide a release where > > they > > > have to answer “yes” when we can provide them a release where they can > > > answer “no”? Based on todays knowledge. (And yes I am aware that a user > > can > > > manually upgrade the jar versions in place after unpacking the > tarballs. > > > Nonetheless.) > > > > > > I disagree that there was a real need to upgrade log4j because 1.x was > > EOL > > > but I won’t argue that staying with old dependencies is automatically > > good. > > > It’s done, anyway. The main point I would like to make here is should a > > > good alternative emerge from this mess I am going to look at replacing > > > log4j 2 with it. Or, if log4j decides to accept the inevitable and > remove > > > the dangerous substitution/rewrite feature then that would be fine too. > > > > > > > On Dec 18, 2021, at 4:42 PM, 张铎 <palomino...@gmail.com> wrote: > > > > > > > > After 2.15.0, all the problems require you manually put some special > > > > markers in the pattern layout in your configuration file, so it is > > > already > > > > less hurt, we do not have something like %m{lookup} in the pattern > > layout > > > > by default. > > > > > > > > Anyway, since we haven’t released 3.0.0-alpha-2 yet, let’s upgrade to > > the > > > > newest version. > > > > > > > > But stay on log4j1 should not be considered as a solution. Log4j1 is > > > > already dead long ago and it has several CVEs where no one wants to > fix > > > > them, and our statement was just ‘do not use the feature’. That’s why > > we > > > > want to migrate to log4j2. Every project may have CVEs, so I think > > > whether > > > > there are still enough people who are still maintaining the project > is > > > the > > > > most important thing. Log4j2 is already the most active logging > > > framework, > > > > another option is logback, but there were no releases for nearly 4 > > years > > > > before 2021… > > > > > > > > Thanks. Let me upgrade the log4j2 to 2.17.0 and send out RC2. > > > > > > > > Andrew Purtell <apurt...@apache.org>于2021年12月19日 周日05:25写道： > > > > > > > >> Apologies, I managed to hit the send button before finishing. My > veto > > > can > > > >> be cured by upgrading Log4J to ** 2.17.0 ** . See > > > >> https://logging.apache.org/log4j/2.x/security.html. > > > >> > > > >>> On Sat, Dec 18, 2021 at 1:22 PM Andrew Purtell < > apurt...@apache.org> > > > >>> wrote: > > > >>> > > > >>> -1 (binding) > > > >>> > > > >>> The Log4J issues are not fixed by 2.15. > > > >>> > > > >>> I wish we had remained on Log4J 1. Hadoop 3 is still on 1, > although I > > > >> know > > > >>> they have plans to upgrade. It does not seem advisable to use > Log4J 2 > > > at > > > >>> all actually. Another option that does not include such a dangerous > > > >>> reference/rewrite mechanism might be preferable. > > > >>> > > > >>>> On Sat, Dec 18, 2021 at 12:02 PM Josh Elser <els...@apache.org> > > > wrote: > > > >>> > > > >>>> +1 (binding) > > > >>>> > > > >>>> * Xsums/sigs good > > > >>>> * Can build from source > > > >>>> * Log4j 2.15 is included (more on this in the below) > > > >>>> * log4j2.formatMsgNoLookups=true is set (multiple times per > process, > > > but > > > >>>> properly set) > > > >>>> * hbase-config.sh issue is fixed over rc1 > > > >>>> > > > >>>> Best as I've been able to keep up, it seems like we should already > > > >>>> upgrade to log4j 2.16 due to issues in 2.15. There are alos > > rumblings > > > >>>> that 2.16 may have issues still. It's my opinion that the changes > we > > > >>>> have here in rc2 are a massive improvement over before. I think > this > > > is > > > >>>> fine; I just wanted to acknowledge that we may still need to > update > > > >>>> again real soon. > > > >>>> > > > >>>> Thanks for your release manager work, Duo! > > > >>>> > > > >>>> On 12/14/21 9:06 AM, Duo Zhang wrote: > > > >>>>> Please vote on this Apache hbase release candidate, > > > >>>>> hbase-3.0.0-alpha-2RC1 > > > >>>>> > > > >>>>> The VOTE will remain open for at least 72 hours. > > > >>>>> > > > >>>>> [ ] +1 Release this package as Apache hbase 3.0.0-alpha-2 > > > >>>>> [ ] -1 Do not release this package because ... > > > >>>>> > > > >>>>> The tag to be voted on is 3.0.0-alpha-2RC1: > > > >>>>> > > > >>>>> https://github.com/apache/hbase/tree/3.0.0-alpha-2RC1 > > > >>>>> > > > >>>>> This tag currently points to git reference > > > >>>>> > > > >>>>> a3ff8e4c812eefab6ad32af45ca449a1395a6510 > > > >>>>> > > > >>>>> The release files, including signatures, digests, as well as > > > >> CHANGES.md > > > >>>>> and RELEASENOTES.md included in this RC can be found at: > > > >>>>> > > > >>>>> https://dist.apache.org/repos/dist/dev/hbase/3.0.0-alpha-2RC1/ > > > >>>>> > > > >>>>> Maven artifacts are available in a staging repository at: > > > >>>>> > > > >>>>> > > > >>>> > > > > https://repository.apache.org/content/repositories/orgapachehbase-1473/ > > > >>>>> > > > >>>>> Artifacts were signed with the 9AD2AE49 key which can be found > in: > > > >>>>> > > > >>>>> https://downloads.apache.org/hbase/KEYS > > > >>>>> > > > >>>>> 3.0.0-alpha-2 is the second alpha release for our 3.0.0 major > > release > > > >>>> line. > > > >>>>> HBase 3.0.0 includes the following big feature/changes: > > > >>>>> Synchronous Replication > > > >>>>> OpenTelemetry Tracing > > > >>>>> Distributed MOB Compaction > > > >>>>> Backup and Restore > > > >>>>> Move RSGroup balancer to core > > > >>>>> Reimplement sync client on async client > > > >>>>> CPEPs on shaded proto > > > >>>>> Move the logging framework from log4j to log4j2 > > > >>>>> > > > >>>>> 3.0.0-alpha-2 contains a critical security fix for addressing the > > > >> log4j2 > > > >>>>> CVE-2021-44228. All users who already use 3.0.0-alpha-1 should > > > upgrade > > > >>>>> to 3.0.0-alpha-2 ASAP. > > > >>>>> > > > >>>>> Notice that this is not a production ready release. It is used to > > let > > > >>>> our > > > >>>>> users try and test the new major release, to get feedback before > > the > > > >>>> final > > > >>>>> GA release is out. > > > >>>>> So please do NOT use it in production. Just try it and report > back > > > >>>>> everything you find unusual. > > > >>>>> > > > >>>>> And this time we will not include CHANGES.md and RELEASENOTE.md > > > >>>>> in our source code, you can find it on the download site. For > > getting > > > >>>> these > > > >>>>> two files for old releases, please go to > > > >>>>> > > > >>>>> https://archive.apache.org/dist/hbase/ > > > >>>>> > > > >>>>> To learn more about Apache hbase, please see > > > >>>>> > > > >>>>> http://hbase.apache.org/ > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Your HBase Release Manager > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >>> -- > > > >>> Best regards, > > > >>> Andrew > > > >>> > > > >>> Words like orphans lost among the crosstalk, meaning torn from > > truth's > > > >>> decrepit hands > > > >>> - A23, Crosstalk > > > >>> > > > >> > > > >> > > > >> -- > > > >> Best regards, > > > >> Andrew > > > >> > > > >> Words like orphans lost among the crosstalk, meaning torn from > truth's > > > >> decrepit hands > > > >> - A23, Crosstalk > > > >> > > > > > > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk >
