>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
