I'm glad to see the activity (!), but I'm having a hard time keeping up with the responses to this thread, sorry if I am out of order.
>> (Leo) Glad you want to help. The original Log4J community left, so to get >> anything done we need some new contributors! I'm fine with skipping the issue tracker, but FWIW I was thinking of using the Log4j 2 JIRA project, not Log4j Bugzilla. https://issues.apache.org/jira/projects/LOG4J2/issues I'm not a fan of enabling GitHub Issues and am not suggesting that. I think we should consider whether the objective is to resurrect Log4j 1.x or just provide a one-time patch along with making it possible to create future one-time patches. Enabling GitHub issues makes it seem like the project is being resurrected, which I do not think it anyone's intention. >> (Leo) comments on the following CVEs > https://nvd.nist.gov/vuln/detail/CVE-2020-9488 > https://nvd.nist.gov/vuln/detail/CVE-2021-4104 The reason I suggested the brute force approach is because I don't think we want to encourage people to keep using 1.x. The brute force approach will be effective with minimal review required. I agree that a great alternative to removal is an empty implementation that preserves the existing interface. >> (Leo) Hmm, that Debian patch is very minimal/conservative WRT CVE-2019-17571, it sounds like you are ahead of the Debian patch, great! That being said, if we aren't trying to resurrect Log4j 1.x for active maintenance, we should favor a simple approach. I'll take a look at your PRs ASAP, but fighting a lot of other Log4Shell fires, so it might take a while. -----Original Message----- From: Vladimir Sitnikov <sitnikov.vladi...@gmail.com> Sent: Friday, December 17, 2021 9:24 AM To: dev@logging.apache.org Subject: Re: JIRA for tracking 1.x release? also some input. >If we do need an issue tracker I would suggest enabling the github one >after making that a writable repo +1. If we need a tracker, then GitHub issues is the way to go. >Note removing the classes would break API compatibility I do not think keeping the class with "every method throws" is much better than just removing the class. However, the CVE in JMSAppender is like "if the attacker can modify logging configuration". Well, in case the attacker can modify configuration files, then you have much worse issues than "reconfiguring log4j". One of the ways to harden that is to limit "acceptable" names to "alphanumeric" or "alphanumeric + slash". I believe lookup for alphanumeric still allows certain cases to work, yet it blocks ldap:// indirections. However, I am not sure if JMSAppender is really used often (nowadays KafkaAppender would get much more love :) ). It might make sense to ship log4j1-nonetwork.jar along with regular log4j.jar Vladimir
