5 ms·

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

deleted 8y ago
[deleted]
the_mitsuhiko 8y ago
Lots of tiny dependencies.
- devcpp 8y ago
  Exactly. As a Java dev, I can't imagine creating a dependency for such a tiny thing. I would want a reputable library. My dependency tree can grow pretty big but not nearly as much as my typical node_modules.
  - thrower123 8y ago
    The thing with Java, and most other popular languages, is that packaging up a unit that small is painful enough that you don't want to do it. For instance, if I was going to do something similar to left-pad in a .NET way, I'd have to create a whole Visual Studio project and build a DLL for a single function, which would rightly be recognized as pants-on-head.
a13n 8y ago
I wish JS/npm was more centralized... I wish there was some centralized authority who took some responsibility for maintaining the security and stability of core packages. I think it'd make sense for npm to be this authority. They're a for-profit organization who benefits most from the success of the npm ecosystem. So why don't they try and take over the most popular projects like left-pad and event-stream? Especially the projects that are small and mostly unmaintained.
gkya 8y ago
> Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? A nasty combination of all of those, probably some more. I was very excited with Node.js when I first heard about it here on HN years ago. I enjoyed watching Dahl's presentation. But as soon as the crowd that went "it's JS, I can document.getElementsByClassName(...), so I can code servers" flocked in and npm became a thing, that was the end of Node.js as a nice, bright little thing. I don't want to defend or encourage gatekeeping, but Node.js brought in lots of folk that did not know what they were doing into software development, and they did not stop to learn a thing or two before creating a monstrosity like npm or making things like leftpad and this possible and popular. And there wasn't any seasoned leaders like Python or Perl communities had, so all that happened with no authoritative opposition. If it was Node.lua or Node.pl, the world would've been a different place today for the software development community.
- joshmanders 8y ago
  > I don't want to defend or encourage gatekeeping Goes on to defend and encourage gatekeeping.
  - gkya 8y ago
    Yes, that's what I do, and thats what the word "but" after the part you quoted indicates. If gatekeeping is bad, not checking who's passing through those gates when they're wide open is worse.
schneidmaster 8y ago
1) Volume -- Javascript is the most popular language right now and it's not really close [1]. Attackers typically focus their efforts on systems that offer the most potential targets. 2) The language -- Javascript has relatively few convenience features in the standard library (at least compared to ruby, which is my point of reference) so more of those features are implemented in userland (and thus imported from npm). I think this is the biggest cause of massive dependency trees -- things like left_pad simply exist natively in many other languages. 3) The ecosystem -- for whatever reason, installing floating package versions was the default for a long time; floating package versions are obviously an order of magnitude more vulnerable to an attacker publishing a malicious update. Edit: 4) I think it's also probably true that Javascript apps are particularly susceptible to this class of vulnerability, but that doesn't necessarily mean they're less secure overall. Javascript teams tend to move quickly and stay on the cutting edge, so they install lots of packages/updates and are thus vulnerable to malicious updates. Equifax's Java app was compromised for exactly the opposite reason -- they didn't install a security update to Apache Struts for months. That class of vulnerability is far less likely to happen on a fast-moving Javascript app. It's all a tradeoff; the important takeaway is to understand the failure modes for your particular stack and be vigilant against them (which in this case means using a lockfile and doing your best to audit new packages/updates). [1] https://insights.stackoverflow.com/survey/2018#most-popular-technologies https://insights.stackoverflow.com/survey/2018#most-popular-...
trickstra 8y ago
- the pervasiveness of left-pad style packages - npm's governance - the community's perspective and culture Also the low-effort nature of javascript language itself - no strong typing, able to rip out or replace foreign methods, even redefine standard behavior, no private methods, ... if somebody enjoys living in such environment, then they are more likely to also be ok with unmaintained packages, npm bumping your package versions without asking, npm allowing anyone to re-take a package name after it was deleted, developers transferring ownership without as much as googling for the username... but hey, as long as they have cool emoji icons...

deleted 8y ago

[deleted]

the_mitsuhiko 8y ago

Lots of tiny dependencies.

devcpp 8y ago
Exactly. As a Java dev, I can't imagine creating a dependency for such a tiny thing. I would want a reputable library. My dependency tree can grow pretty big but not nearly as much as my typical node_modules.
- thrower123 8y ago
  The thing with Java, and most other popular languages, is that packaging up a unit that small is painful enough that you don't want to do it. For instance, if I was going to do something similar to left-pad in a .NET way, I'd have to create a whole Visual Studio project and build a DLL for a single function, which would rightly be recognized as pants-on-head.

a13n 8y ago

I wish JS/npm was more centralized... I wish there was some centralized authority who took some responsibility for maintaining the security and stability of core packages. I think it'd make sense for npm to be this authority. They're a for-profit organization who benefits most from the success of the npm ecosystem. So why don't they try and take over the most popular projects like left-pad and event-stream? Especially the projects that are small and mostly unmaintained.

gkya 8y ago

> Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? A nasty combination of all of those, probably some more. I was very excited with Node.js when I first heard about it here on HN years ago. I enjoyed watching Dahl's presentation. But as soon as the crowd that went "it's JS, I can document.getElementsByClassName(...), so I can code servers" flocked in and npm became a thing, that was the end of Node.js as a nice, bright little thing. I don't want to defend or encourage gatekeeping, but Node.js brought in lots of folk that did not know what they were doing into software development, and they did not stop to learn a thing or two before creating a monstrosity like npm or making things like leftpad and this possible and popular. And there wasn't any seasoned leaders like Python or Perl communities had, so all that happened with no authoritative opposition. If it was Node.lua or Node.pl, the world would've been a different place today for the software development community.

joshmanders 8y ago
> I don't want to defend or encourage gatekeeping Goes on to defend and encourage gatekeeping.
- gkya 8y ago
  Yes, that's what I do, and thats what the word "but" after the part you quoted indicates. If gatekeeping is bad, not checking who's passing through those gates when they're wide open is worse.

schneidmaster 8y ago

1) Volume -- Javascript is the most popular language right now and it's not really close [1]. Attackers typically focus their efforts on systems that offer the most potential targets. 2) The language -- Javascript has relatively few convenience features in the standard library (at least compared to ruby, which is my point of reference) so more of those features are implemented in userland (and thus imported from npm). I think this is the biggest cause of massive dependency trees -- things like left_pad simply exist natively in many other languages. 3) The ecosystem -- for whatever reason, installing floating package versions was the default for a long time; floating package versions are obviously an order of magnitude more vulnerable to an attacker publishing a malicious update. Edit: 4) I think it's also probably true that Javascript apps are particularly susceptible to this class of vulnerability, but that doesn't necessarily mean they're less secure overall. Javascript teams tend to move quickly and stay on the cutting edge, so they install lots of packages/updates and are thus vulnerable to malicious updates. Equifax's Java app was compromised for exactly the opposite reason -- they didn't install a security update to Apache Struts for months. That class of vulnerability is far less likely to happen on a fast-moving Javascript app. It's all a tradeoff; the important takeaway is to understand the failure modes for your particular stack and be vigilant against them (which in this case means using a lockfile and doing your best to audit new packages/updates). [1] https://insights.stackoverflow.com/survey/2018#most-popular-technologies https://insights.stackoverflow.com/survey/2018#most-popular-...

trickstra 8y ago

- the pervasiveness of left-pad style packages - npm's governance - the community's perspective and culture Also the low-effort nature of javascript language itself - no strong typing, able to rip out or replace foreign methods, even redefine standard behavior, no private methods, ... if somebody enjoys living in such environment, then they are more likely to also be ok with unmaintained packages, npm bumping your package versions without asking, npm allowing anyone to re-take a package name after it was deleted, developers transferring ownership without as much as googling for the username... but hey, as long as they have cool emoji icons...