There are 3 new CVEs for log4j1 reported recently[1][2][3]. So I think it is time to speed up the migration to log4j2 work[4] now.
You can see the discussion on the jira issue[4], our goal is to fully migrate to log4j2 and the current most blocking issue is lack of the "log4j.rootLogger=INFO,Console" grammer support for log4j2. I've already started a discussion thread on the log4j dev mailing list[5] and the result is optimistic and I've filed an issue for log4j2[6], but I do not think it could be addressed and released soon. If we want to fully migrate to log4j2, then either we introduce new environment variables or split the old HADOOP_ROOT_LOGGER variable in the startup scripts. And considering the complexity of our current startup scripts, the work is not easy and it will also break lots of other hadoop deployment systems if they do not use our startup scripts... So after reconsidering the current situation, I prefer we use the log4j1.2 bridge to remove the log4j1 dependency first, and once LOG4J2-3341 is addressed and released, we start to fully migrate to log4j2. Of course we have other problems for log4j1.2 bridge too, as we have TaskLogAppender, ContainerLogAppender and ContainerRollingLogAppender which inherit FileAppender and RollingFileAppender in log4j1, which are not part of the log4j1.2 bridge. But anyway, at least we could just copy the source code to hadoop as we have WriteAppender in log4j1.2 bridge, and these two classes do not have related CVEs. Thoughts? For me I would like us to make a new 3.4.x release line to remove the log4j1 dependencies ASAP. Thanks. 1. https://nvd.nist.gov/vuln/detail/CVE-2022-23302 2. https://nvd.nist.gov/vuln/detail/CVE-2022-23305 3. https://nvd.nist.gov/vuln/detail/CVE-2022-23307 4. https://issues.apache.org/jira/browse/HADOOP-16206 5. https://lists.apache.org/thread/gvfb3jkg6t11cyds4jmpo7lrswmx28w3 6. https://issues.apache.org/jira/browse/LOG4J2-3341
