Oh wow. I didn't realise there has been yet another log4j update because of anew vulnerability. We're now up to 2.17.
This new one is harder to exploit, and is not an RCE so it's not as bad, but still. This is just more proof that log4j s an overengineered mess. I've been of this opinion for years.
I'm not going to claim credit for predicting this, because I never actually saw it as a huge security vulnerability. I just considered it something that people spend far too much effort on. When you're invested in a piece of software, you keep tinkering with it and add new features when none are needed. Logging should be a solved problem, and Java already comes with a logging API. log4j has no real reason to exist other than momentum.
@loke is JUL a good logging API though?
Being also a Python coder, I'm sympathetic to the idea that we'd all be better off if the standard library logging framework was used by everyone. Java developers somehow missed making a particularly good framework. Maybe, eventually slf4j and log4j enter the java.* namespace in the way joda time did...
one developer's journey from JUL: https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging
@loke I'm not saying you're wrong about log4j bring over-engineered, just that it has a reason for being
@2ck Yeah, that's true. The reason for existing is that log4j came out before java.util.logging was part of Java.
I've used java.util.logging a lot, and it does everything I've ever needed. Of course, log4j does more, but I argue we'd all have been better off if it didn't. It was feature creep that caused the RCE vulnerability after all.
I think the problem is that java.util.logging wasn't significantly better than log4j, which meant that there was enough inertia to keep people on log4j.
(and now I'm going on a bit of a rant, it's not against you. It's just that log4j is such an example of everything that's wrong with the way third party libraries are developed)
And once you have a large open source project that a lot of people use, its maintainers still want to implement cool new features, because that's a lot more fun that fixing bugs. But something like log4j should not be a project where cool new features are added. Those should be built on top, as optional supplementary libraries that people can use if they want to.
No one (and I'm fairly certain that the total number of people is actually zero) wants to do JNDI lookups in a logger parameter. What people want to do, however, is to log strings that contain arbitrary content. log4j is optimised for the former case, and making the obvious straightforward use case very difficult to the point that only a minority of developers even knew one needed special escaping to avoid it.
The more I think about this thing, the more angry I get. It's so obvious that the developers of these features did it because they can, not because anyone wants it. This is proven further by the fact that after this lookup stuff was added, it wasn't even added to the documentation. The documentation wasn't updated until years later.
@loke oh no, don't be angry 😣😁
I'm not going to dig through log4j's history to see whether there was a feature request for the jndi junk, but I'd hope there was a legit reason for it. as I understand, the real f'd up thing is in how variable resolution is designed and implemented. it's wild that resolution of vars like that is even possible in the message string vs the code that handles the format string from logging system configuration.
it's also wild to me that library devs wouldn't take the approach you describe for extensibility if it is possible. I have an idea, then I have to get it out, (and make it useful because I'm a nice guy) but then I'm doing my best to make anything outside of the core very not my problem. no interest in building my own prison
