When a Java logging package has a vulnerability: Sober introspection about the role of maintainers, dependencies, and backward compatibility in the OSS ecosystem.
When a Java logging package has a vulnerability: Sober introspection about the role of maintainers, dependencies, and backward compatibility in the OSS ecosystem.
Which is nominally true for Java. But Java enjoys the advantage of maturity. These things are supposed to have been foreseen. Java projects have a lot more resources thrown at them by their orgs, and there is a great deal of talent out there making sure all of this stuff is reliable.
This... caught that whole ecosystem off guard. Javascript devs have to always be on guard, because Javascript is the wild west. Nobody blissfully using and loving Javascript really understands why Javascript has so much trouble coming up with a standard library, but anyone who gets deep enough into Java understands very painfully why you just can't rely on it like you can Java.
Nobody starts asking sober, realistic questions when Javascript breaks because Javascript is always breaking.
Which is why its just a stupid to be angry with java regarding this.
Don't get me wrong, NodeJS is improving... by implementing Ruby features.
Well yeah. It never claimed to have one.
You're blaming an ecosystem for being unstable, which while I agree, ultimately has nothing to do with the lang itself.
The fact we're discussing the fact one of the most simple libs of a language (logging to the console) can have such a widely felt exploit in such a 'mature' lang makes you're entire point very ironic.
It has everything to do with the language. With no built-in module support (until recently!) and a weak type system, it's virtually impossible for Javascript to get anywhere near the stability of Java.
> makes you're entire point very ironic.
OP made an observation that we're having this conversation for this particular Java vuln but Javascript breakage never provokes anything like this. I don't understand where the ironing is. <insert-Princess-Bride-gif>
With Java, though, a lot of the services in production were made before this maturity was standard. There's a vast amount of software out there that's insufficiently tested and documented, some of which has dependencies as jar files included directly in the filesystem, and the relative stability of the Java library ecosystem led to a feeling that this was acceptable. It's difficult to even detect vulnerable services, much less upgrade them and trust CI to have your back. The reason this CVE is insidious is because it uniquely affects legacy software, often many layers removed from web interfaces, that was thought to be battle-tested.