Conversation

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 :(

Quote Tweet

Chriscreama Warren

@film_girl

Dec 18, 2021

Third Log4j CVE

logging.apache.org/log4j/2.x/secu

119

685

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

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

Replying to

and

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.

Replying to

and

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

Replying to

and

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.

Replying to

and

I don't think rewriting history about this is right. log4j1 was already doing far too much for a logging library which should have been done with a proper logging service. log4j2 turned that up to 11 and has dramatically more complexity. It's also not the same project.

4:22 PM · Dec 19, 2021Twitter Web App

Replying to

and

The original project was continued as logback. Most code is really still using log4j1 and the closest upgrade from that is moving to logback, not log4j2. I think most people would be fine with using the far more minimal java.util.logging with the lambda API for lazy evaluation.

Replying to

and

The main reason to use logback over java.util.logging is if you log ridiculous amounts of data and need higher performance. Vast majority of server-side software should just be sending logs to a logging service and really doesn't need a third party logging implementation at all.