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 > >> >
