5 ms·

When a Javascript logging package has a vulnerability: "Why do you need a package for something so basic as logging? This should be part of JS core lib, or just

When a Javascript logging package has a vulnerability: "Why do you need a package for something so basic as logging? This should be part of JS core lib, or just roll your own." When a Java logging package has a vulnerability: Sober introspection about the role of maintainers, dependencies, and backward compatibility in the OSS ecosystem.

notreallyserio 5y ago
Yeah but one uses npm and the other maven.
- yjftsjthsd-h 5y ago
  So it's all glass houses?
vinceguidry 5y ago
Honestly speaking, nobody should be surprised by this. Javascript on the server is a daft pursuit, and shops that rely on it are continuously rolling the dice on their uptime anyway. Anyone can release a NodeJS package, and anyone can pick it up as a dependency. 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.
- breakfastduck 5y ago
  Absolutely awful attitude to have. Javascript is not always breaking. Blaming failures of libraries on the language itself is ridiculous. Literally JS on the server is no more vulnerable to downtime than other langs. Which is why its just a stupid to be angry with java regarding this.
  - vinceguidry 5y ago
    Get far enough in your career and you realize ecosystems and history, and yes, language dynamics, matter. Javascript never had a module management system. It never had anything close to a strong type system. (at least python and ruby have strong type systems) All these things have to be grafted onto the language later and if you can understand the tyranny backwards-compatibility places a language under, you can understand the plight of NodeJS. Don't get me wrong, NodeJS is improving... by implementing Ruby features.
    - breakfastduck 5y ago
      > It never had anything close to a strong type system 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.
      - vinceguidry 5y ago
        > You're blaming an ecosystem for being unstable, which while I agree, ultimately has nothing to do with the lang itself. 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>
- btown 5y ago
  There are different times, though. If you're going to roll a service in server-side Javascript at a large organization nowadays, it'll be tested to high heaven with modern CI/CD and rolling deploys, and this mitigates the fragility of applying security (or any other) updates significantly. 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.
vultour 5y ago
Quite a reach going from the typical mockery of JavaScript that mostly refers to the left-pad fiasco, to saying logging is expected as a core library. No language I've used so far had a built-in logging library that was useful in every project.
throwaway19937 5y ago
These aren't conflicting beliefs. It's perfectly reasonable to believe that JavaScript has an inadequate standard library and recognize that other ecosystems can have dependency issues.

notreallyserio 5y ago

Yeah but one uses npm and the other maven.

yjftsjthsd-h 5y ago
So it's all glass houses?

vinceguidry 5y ago

Honestly speaking, nobody should be surprised by this. Javascript on the server is a daft pursuit, and shops that rely on it are continuously rolling the dice on their uptime anyway. Anyone can release a NodeJS package, and anyone can pick it up as a dependency. 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.

breakfastduck 5y ago
Absolutely awful attitude to have. Javascript is not always breaking. Blaming failures of libraries on the language itself is ridiculous. Literally JS on the server is no more vulnerable to downtime than other langs. Which is why its just a stupid to be angry with java regarding this.
- vinceguidry 5y ago
  Get far enough in your career and you realize ecosystems and history, and yes, language dynamics, matter. Javascript never had a module management system. It never had anything close to a strong type system. (at least python and ruby have strong type systems) All these things have to be grafted onto the language later and if you can understand the tyranny backwards-compatibility places a language under, you can understand the plight of NodeJS. Don't get me wrong, NodeJS is improving... by implementing Ruby features.
  - breakfastduck 5y ago
    > It never had anything close to a strong type system 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.
    - vinceguidry 5y ago
      > You're blaming an ecosystem for being unstable, which while I agree, ultimately has nothing to do with the lang itself. 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>
btown 5y ago
There are different times, though. If you're going to roll a service in server-side Javascript at a large organization nowadays, it'll be tested to high heaven with modern CI/CD and rolling deploys, and this mitigates the fragility of applying security (or any other) updates significantly. 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.

vultour 5y ago

Quite a reach going from the typical mockery of JavaScript that mostly refers to the left-pad fiasco, to saying logging is expected as a core library. No language I've used so far had a built-in logging library that was useful in every project.

throwaway19937 5y ago

These aren't conflicting beliefs. It's perfectly reasonable to believe that JavaScript has an inadequate standard library and recognize that other ecosystems can have dependency issues.