Re: JNDI concerns
And yet they have done it with extreme prejudice haven't they, they've taken option-b and rightly so, but the decision to enable it by default is basically down to the Apache committer.
If you look at the log4j jira and search for the original ticket (https://issues.apache.org/jira/browse/LOG4J2-313); the use-case seems reasonable on the face of it. With hindsight "we can all say, there's no way that's secure, don't be soft!". But, think about the sea change in security perspective in the intervening 8 years. How many of us employed by corporates have now been on mandatory secure-by-design training. If you've been with the same company for a while, when did the powers-that-be mandate it? (I suspect it was post equifax...)
Developers are ultimately lazy and haven't been forced to have the discipline to consider all the side-effects of their changes on the entire system.
To take a case in point, the javax package move to jakarta is one that irks me, because they've broken backwards compatibility in a completely nonsensical way. jakarta.mail.jar contains some "com.sun.mail" packages in situ, but have renamed all the javax.mail -> jakarta.mail. There's a circular dependency in one of the classes (a com.sun.mail class now takes a jakarta.mail class; this conflicts the same class that might have been provided by javamail-api.jar, because method signatures right)
They committed the change, the unit tests passed, so they released jakarta.mail-2.0.0, because the unit tests passed 100% code coverage. It's all good.
There are a lot of things out that that still depend on javax.mail.*, but this means that you can't include javamail-api-1.6.2.jar and jakarta.mail-2.0.1.jar in your classpath. Backwards compatibility is now broken irretrievably; there will be projects that pull an open source library that is orphaned (but serves its purpose) that depends on javax.mail (because javax.mail.mime isn't awful) and they can't upgrade to jakarta.mail to take advantage of security updates because they need working software.