On Thu, 20 Jan 2022 at 17:15, Andrew Purtell <andrew.purt...@gmail.com> wrote:
> Just to clarify: I think you want to upgrade to Log4J2 (or switch to > LogBack) as a strategy for new releases, but you have the option in > maintenance releases to use Reload4J to maintain Appender API and > operational compatibility, and users who want to minimize risks in > production while mitigating the security issues will prefer that. i like this > > > > On Jan 20, 2022, at 8:59 AM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > > Reload4J has fixed all of those CVEs without requiring an upgrade. > > > >> On Jan 20, 2022, at 5:56 AM, Duo Zhang <zhang...@apache.org> wrote: > >> > >> 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > >
