You know what might encourage a faster pace of remediation? If the Log4j jackasses had readable documentation about their dogshit configuration syntax that wasn’t written by someone who, while I would never call them a fucking moron personally, writes documentation in a manner that is indistinguishable from the way a fucking moron writes documentation.
Frankly, half of log4j’s problem is it’s ridiculous amounts of overkill in how it approaches the problem. The adapter pattern is everywhere because there might be a need at some point within the next three or four millennia to swap out this or that component in the logging system. Interfaces and Impls and bullshit everywhere, and boilerplate code as far as the eye can see.
It happens all the time within the development community. There’s very little consideration about when to employ a pattern, it’s just cargo culting this or that and shoveling shit into the “ship it” bin (for which I blame shitty management, but I digress). Very often I’m counseling my juniors to step back their solutions away from things that better resemble Rube Goldberg machines in favor of something far simpler.
Lately, simplicity has been seen as overrated, but from both an engineering and a security perspective, I can’t disagree more with that sentiment. Less moving parts is less attack surface, less to maintain, less to go wrong.
How to say “open source documentation” without saying “open source documentation.”
Apache in a nutshell.
The whole premise of even having this feature at all is so dogshit brainfck bonkers, it is beyond insane.
A ton of their stuff is the whitest highest ivory tower of academia furthest removed from real life.
Just get tinylog and throw log4j out.
If only there was some way to disable JNDI and/block outbound traffic
I’m pretty sure those installations who are STILL vulnerable 6 months in… wouldn’t even know how to do any of that nor has anything reached them in terms of news they need to change something.