This isn't because Log4j is doing anything wrong; this is because of increased scrutiny and eyeballs.
I do not envy the team having to work under this microscope :(
Conversation
Replying to
Certainly they’re not doing anything newly wrong, but in general having eval() in any logging library would have people aghast if it was newly created now. Sadly it slipped by unnoticed for years
1
9
Replying to
It was a deliberate "feature" they had to keep around for backwards compatibility :( they knew it was risky but previously didn't feel they could break it
4
11
It wasn't added that long ago and I don't think they had any intention of removing it. It was regarded as a useful feature and definitely wasn't just kept around for backwards compatibility.
log4j1 didn't have the feature and it's one of many things that got added with log4j2.
My understanding was that it shipped with the first release of log4j2 (2.0) in 2014 which is an eon ago in terms of secure software
1
A much earlier version of it shipped then which continued to be expanded and fully supported until very recently. It was enabled by default, there was no deprecation and there's no indication that they wanted to remove it rather than seeing it as a useful non-problematic feature.
1
Show replies
log4j1 was the defacto standard logging library in the Java ecosystem before the far simpler and more reasonable java.util.logging was added to the standard library. Since it was so broadly adopted, it still has far more users than log4j2 or the standard library logging module.
1
log4 was very complex and duplicates the functionality of system logging services like rsyslog. The original developer left Apache and continued their work with SLF4J and logback. Apache decided to continue using the valuable log4j brand name for a much more complex rewrite.
1
1
Show replies