6 ms·

What is it about nodejs/NPM in specific that leads to malicious changes being so noteworthy/significant? I barely never see anything about other package indexe

What is it about nodejs/NPM in specific that leads to malicious changes being so noteworthy/significant? I barely never see anything about other package indexes (crates.io, PyPI, etc). Doesn't npm also use a lock file by default for packages?

ElectricalUnion 5y ago
NPM default "package-lock.json" lock files only prevent your immediate dependencies from changing. If a transitive dependency (the majority of them) have changed, you're out-of-luck.
- maxloh 5y ago
  If I recall it right, `npm ci` installs the exact same version defined in package-lock.json, for all dependencies.
rfoo 5y ago
npm lock file is platform-dependent, so people are reluctant to check it in.
johnny22 5y ago
you missed the package typo name hijacks on pypi that installed malware?
feross 5y ago
There's a few reasons. First, the scale of the JavaScript ecosystem. JavaScript is so much larger than every other ecosystem, so even a very small probability event (somebody introducing malware into a package) can happen surprisingly often given the scale of the ecosystem. Supply chain attacks are a problem in all open source ecosystems – not just JS – but they are a bit rarer and don't effect as many people so fewer people take note. Second, npm was one of the first package managers to solve the classic "dependency hell" problem. In Python, if you have two dependencies, A and B, which both depend on different versions of C, say C@1.0.0 and C@2.0.0, respectively, then you're in trouble. You have an broken project. Python can only install one version of C. So now you're in dependency hell. Npm on the other hand just installs both versions of C and it gives A the version that it wants, C@1.0.0. And it gives B the version that it wants, C@2.0.0. Both packages are happy - problem solved. This caused Python maintainers to think twice before adding a new dependency lest they cause "dependency hell" for their users. Much better to just copy paste these 50 lines of code rather than adding a dependency. So there was an intrinsic sort of resistance – some pain is involved in adding new dependencies. Npm maintainers had no such constraints. In a way, npm’s better developer experience led to the whole module ecosystem scaling "too well". Disclosure: I started Socket (https://socket.dev https://socket.dev) to help solve open source supply chain security. To learn more, see: https://news.ycombinator.com/item?id=30521913 https://news.ycombinator.com/item?id=30521913
- Nicksil 5y ago
  >Python maintainers would think twice before adding a new dependency lest they cause "dependency hell" for their users. So there was an intrinsic sort of resistance – some pain is involved in adding new dependencies. Well, no, it's because the standard library is so good.
  - deleted 5y ago
    [deleted]
  - bliteben 5y ago
    both
  - leshenka 5y ago
    I don't know if there is a way to objectively compare "good"-ness of standard libraries but more often than not, I'm missing JS sugar when coding in python than python sugar when coding in JS.
pluc 5y ago
nodejs is full of "full-stack developers" that used to be "front-end engineers" or "integrators" 10-ish years ago. In a lot of cases, they do not come from a CS background but a more creative one due to the related tasks their profession used to have to deal with before js and node exploded (eg slicing templates), thus are less aware of/strict on security risks and issues. That's biased as hell but it's been my experience
- fshbbdssbbgdd 5y ago
  This is what’s known as a “just-so story”. In an alternate universe you could tell the same story to explain why js devs only copy/paste code and never use dependencies because they can’t wrap their heads around a complex dependency graph and the required tooling.
- arealaccount 5y ago
  Its basically a social network for new developers.
  - cphoover 5y ago
    explain this comment?
    - arealaccount 5y ago
      Npm is primarily hosted out of github where your code posts get stars, followers, etc. This drives user engagement, encourages tons of content, and helps new entrants network with other developers. There is good content in there for sure but it’s mostly just the code versions of Facebook posts
- cphoover 5y ago
  Really terrible take seeing as Javascript devs span all areas of focus and every level of experience, and education. I've seen plenty programmer's with CS degrees make terribly dumb mistakes, and some self-taught developers are some of the smartest people I've worked with. There are more javascript developers, because JS is far and away the most popular programming environment due mainly to its ubiquity on the web. Because of that the JS supply-chain is a much larger attack surface than most languages.
runarberg 5y ago
The size of the ecosystem. Industrial sabotage happens in most industries and JavaScript developers are no exception. This particular industry is huge. It contains millions of workers, some of which are politically motivated to engage in this kind of sabotage. The potential reach is even larger. And a well performed sabotage can potentially affect millions of people inside or outside the industry without putting the saboteur in that big of a risk. I’m actually surprised we don’t see more of this.

ElectricalUnion 5y ago

NPM default "package-lock.json" lock files only prevent your immediate dependencies from changing. If a transitive dependency (the majority of them) have changed, you're out-of-luck.

maxloh 5y ago
If I recall it right, `npm ci` installs the exact same version defined in package-lock.json, for all dependencies.

rfoo 5y ago

npm lock file is platform-dependent, so people are reluctant to check it in.

johnny22 5y ago

you missed the package typo name hijacks on pypi that installed malware?

feross 5y ago

There's a few reasons. First, the scale of the JavaScript ecosystem. JavaScript is so much larger than every other ecosystem, so even a very small probability event (somebody introducing malware into a package) can happen surprisingly often given the scale of the ecosystem. Supply chain attacks are a problem in all open source ecosystems – not just JS – but they are a bit rarer and don't effect as many people so fewer people take note. Second, npm was one of the first package managers to solve the classic "dependency hell" problem. In Python, if you have two dependencies, A and B, which both depend on different versions of C, say C@1.0.0 and C@2.0.0, respectively, then you're in trouble. You have an broken project. Python can only install one version of C. So now you're in dependency hell. Npm on the other hand just installs both versions of C and it gives A the version that it wants, C@1.0.0. And it gives B the version that it wants, C@2.0.0. Both packages are happy - problem solved. This caused Python maintainers to think twice before adding a new dependency lest they cause "dependency hell" for their users. Much better to just copy paste these 50 lines of code rather than adding a dependency. So there was an intrinsic sort of resistance – some pain is involved in adding new dependencies. Npm maintainers had no such constraints. In a way, npm’s better developer experience led to the whole module ecosystem scaling "too well". Disclosure: I started Socket (https://socket.dev https://socket.dev) to help solve open source supply chain security. To learn more, see: https://news.ycombinator.com/item?id=30521913 https://news.ycombinator.com/item?id=30521913

Nicksil 5y ago
>Python maintainers would think twice before adding a new dependency lest they cause "dependency hell" for their users. So there was an intrinsic sort of resistance – some pain is involved in adding new dependencies. Well, no, it's because the standard library is so good.
- deleted 5y ago
  [deleted]
- bliteben 5y ago
  both
- leshenka 5y ago
  I don't know if there is a way to objectively compare "good"-ness of standard libraries but more often than not, I'm missing JS sugar when coding in python than python sugar when coding in JS.

pluc 5y ago

nodejs is full of "full-stack developers" that used to be "front-end engineers" or "integrators" 10-ish years ago. In a lot of cases, they do not come from a CS background but a more creative one due to the related tasks their profession used to have to deal with before js and node exploded (eg slicing templates), thus are less aware of/strict on security risks and issues. That's biased as hell but it's been my experience

fshbbdssbbgdd 5y ago
This is what’s known as a “just-so story”. In an alternate universe you could tell the same story to explain why js devs only copy/paste code and never use dependencies because they can’t wrap their heads around a complex dependency graph and the required tooling.
arealaccount 5y ago
Its basically a social network for new developers.
- cphoover 5y ago
  explain this comment?
  - arealaccount 5y ago
    Npm is primarily hosted out of github where your code posts get stars, followers, etc. This drives user engagement, encourages tons of content, and helps new entrants network with other developers. There is good content in there for sure but it’s mostly just the code versions of Facebook posts
cphoover 5y ago
Really terrible take seeing as Javascript devs span all areas of focus and every level of experience, and education. I've seen plenty programmer's with CS degrees make terribly dumb mistakes, and some self-taught developers are some of the smartest people I've worked with. There are more javascript developers, because JS is far and away the most popular programming environment due mainly to its ubiquity on the web. Because of that the JS supply-chain is a much larger attack surface than most languages.

runarberg 5y ago

The size of the ecosystem. Industrial sabotage happens in most industries and JavaScript developers are no exception. This particular industry is huge. It contains millions of workers, some of which are politically motivated to engage in this kind of sabotage. The potential reach is even larger. And a well performed sabotage can potentially affect millions of people inside or outside the industry without putting the saboteur in that big of a risk. I’m actually surprised we don’t see more of this.