I graduated in 1990 in Electrical Engineering and since then I have been in university, doing research in the field of DSP. To me programming is more a tool than a job.
Yes, you read it right. It works as documented. It is not a bug, it is a feature, really.
What you can blame on log4j is feature creep, that made log4j handling tasks that go beyond the duty of a logging library.
A logging library should do one thing: take a string, together with a "severity" and save it somewhere. The string should be an opaque, binary blob and no processing should be done by the library. Stop.
Who actually is to blame for the problem is who used this library
You decided to use a library that has a very dangerous feature (remember, not a bug). To make a simile: suppose I make an http server that with some "magic URL" gives you access to a shell on the server (e.g. example.com/.shell/?command="rm -rf /"). Clearly a convenient, but very dangerous feature. Would you install such a server? I wouldn't.
You decided anyway to use log4j (maybe you had some constraint that forced you using it). OK, then at least do some sanitation on the material that you receive from outside!! Come on! It is Good Practices 101. Remember Little bobby tables of xkcd?
Conclusion? Should I assign blame in this matter I would do as follows
10% to log4j library for "extreme feature creep"
90% to log4j users for choosing a library with dangerous features and using it carelessly.
Programming languages enthusiast. Author of Learn Type Driven Development: https://www.packtpub.com/application-development/learn-type-driven-development
Yes very good point. Not really related to the point I am trying to make in my post, which is that people are expecting log4j maintainers to automatically jump into action during nights and weekends to save their hides–for free.
That's an interesting comment. As I explain in my post Log4j vulnerability: What the FAQ happened?, the feature was there and intentional (so yes, not broken in that sense), but was never properly documented.
And regarding sanitation/sanitization, OWASP is one of the best authorities on best practices, and they specifically did not recommend sanitization for log4j 2. You're cordially invited to provide a citation for Good Practices 101 that advises otherwise.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
log4j is not broken
Stop blaming log4j
Yes, you read it right. It works as documented. It is not a bug, it is a feature, really.
What you can blame on log4j is feature creep, that made log4j handling tasks that go beyond the duty of a logging library.
A logging library should do one thing: take a string, together with a "severity" and save it somewhere. The string should be an opaque, binary blob and no processing should be done by the library. Stop.
Who actually is to blame for the problem is who used this library
Conclusion? Should I assign blame in this matter I would do as follows
Yes very good point. Not really related to the point I am trying to make in my post, which is that people are expecting log4j maintainers to automatically jump into action during nights and weekends to save their hides–for free.
That's an interesting comment. As I explain in my post Log4j vulnerability: What the FAQ happened?, the feature was there and intentional (so yes, not broken in that sense), but was never properly documented.
And regarding sanitation/sanitization, OWASP is one of the best authorities on best practices, and they specifically did not recommend sanitization for log4j 2. You're cordially invited to provide a citation for Good Practices 101 that advises otherwise.