Hey Gary, On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> If you delete anything that is public or protected, you will break > binary compatibility, and that's a no-go IMO. Agree. I hope we can get clirr (or something like it) back to work, to prove binary compatibility. Perhaps with one exception: Initially what I did for the classes that start up servers is to disable their behavior. But Vladimir convinced me it's better to remove them. Some reasoning: * it's easier to understand and easier to audit. * it also matches common advice across the internet to delete things from the jars. * very unlikely someone subclassed. * if they did subclass, it is very unlikely an upgrade to 1.2.18 makes sense for them. * if people are running these daemons, we can't really hope to secure it for them, so they can stay on 1.2.17. So I caved and on the draft PR I now deleted net.JMSSink / net.SocketServer / net.SimpleSocketServer / jmx.Agent. https://github.com/apache/log4j/pull/16/commits/911fc233742c1c85668c22873b8b913623d91680 https://github.com/apache/log4j/pull/16/commits/246b0439a779575f2bae573e55dd4cad077e2ca0 What do you think, are these ok exceptions to you? Technically it's easy enough to do either way but I can't do both :) > If are going to really > want to release anything, you'll want to disable JNDI by default and > add an enablement property as we did for 2.17.0. > Hmm, I wasn't really intending to allow re-enabling JNDI, instead I just disabled JMS completely: https://github.com/lsimons/log4j/blob/2021-security-fixes/src/main/java/org/apache/log4j/net/JMSAppender.java#L44 Some reasoning: * If you're ok with doing your log4j security 'around' the package (i.e. solid network firewall / trusted sources & targets, conservative config file), in practice you can just stay on 1.2.17. * If not, then 1.2.18 can just disable everything 'worrisome' for you. * If you need more flexibility / want a maintained secure way to do JMS/SMTP/etc: upgrade to 2.x! Does that make sense? Cheers, Leo
