4 ms·

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

by amiga386 1y ago

a4isms 1y ago
Deeply underrated comment. You can peel back the layers of sarcasm like... An onion.
- deleted 1y ago
  [deleted]
- TZubiri 1y ago
  Btw, it's copypasta at this stage
  - a4isms 1y ago
    Anyone familiar with The Onion knows this, The Onion themselves repost the exact same thing every time there's a school shooting. Which emphasizes how regularly it happens, and therefore in turn I have no objection to a joke like this becoming copy pasta every time an NPM supply chain attack takes place. https://duckduckgo.com/?q=site%3Atheonion.com+%22no+way+to+prevent+this%22 https://duckduckgo.com/?q=site%3Atheonion.com+%22no+way+to+p...
andrewl-hn 1y ago
TBF it does happen to other package managers, too. There were similar attacks on PyPI and Rubygems (and maybe others). However, since npm is the largest one and has the most packages released, updated, and downloaded, it became the primary target. Similar to how computer viruses used to target Windows first and foremost due to its popularity. Also, smaller package managers tend to learn from these attacks on npm, and by the time the malware authors try to use similar types of attacks on them the registries already have mitigations in place.
- shakna 1y ago
  PyPI is working towards attestation [0], and already has "Trusted Publisher" [1]. Ruby has had signed gems since v2 [2]. These aren't a panacea. But they do mean an effort has been made. npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4] I don't think it's fair to compare npm to the others. [0] https://docs.pypi.org/attestations/producing-attestations/ https://docs.pypi.org/attestations/producing-attestations/ [1] https://docs.pypi.org/trusted-publishers/ https://docs.pypi.org/trusted-publishers/ [2] https://docs.ruby-lang.org/en/master/Gem/Security.html https://docs.ruby-lang.org/en/master/Gem/Security.html [3] https://github.com/npm/npm/pull/4016 https://github.com/npm/npm/pull/4016 [4] https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29
  - madeofpalk 1y ago
    NPM has both Trusted Publishing and provenance claims for where packages are built. https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements Trusted Publishing is relatively new - GA-ed in July https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ https://github.blog/changelog/2025-07-31-npm-trusted-publish...
    - otterley 1y ago
      Trusted Publishing is a marketing term—a fancy name for OIDC support and temporary auth token issuance. It delegates authenticating the uploader to their identity provider, nothing more. In a very real sense, it shifts responsibility to someone else. For example, if the uploader was using Google as their identity provider and their Google account was popped, the attacker would be able to impersonate the uploader. So I wouldn’t describe it as establishing a strong trust relationship with the uploader. It only meaningfully improves the security of the NPM ecosystem if (a) everyone is forced to sign packages and (b) identity providers require more secure authentication methods with as hardware tokens or passkeys.
    - 1y ago
h1fra 1y ago
It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm
- izacus 1y ago
  What about Java's Maven, much more popular and longer living?
  - simonw 1y ago
    What makes you think Maven is more popular?
  - rs186 1y ago
    When your only dependencies are Spring and Apache Commons, which requires legal approval in your corporation to use, and each update requires scrutiny, it's hard to get any supply chain attacks, right?
- amiga386 1y ago
  As far as I remember: "go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run) Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u" You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher would get pwned while working on something unrelated. The Go community tends not to "micropublish" so fewer people have or need commit rights to published go modules. Go has a decent standard library so there are fewer "missing core functionality" third-party packages that world + dog depends on. Npm is easier to pwn than Go, Maven, RubyGems, PyPI, CPAN, etc. because the design has more footguns and its community likes it that way
  - h1fra 1y ago
    postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.
acdha 1y ago
This is funny but ultimately a mischaracterization of a popularity contest. Node culture is extreme–perhaps pathological–about using many dependencies to work around the limited standard library but the same kind of attacks happen everywhere people are releasing code. The underlying problem is that once you release something it takes only seconds before someone else can be running your code with full privileges to access their account. That’s why the joke doesn’t really work: America is a huge outlier for gun violence because we lack structural protections. Australia doesn’t have fewer attacks in proportion to a smaller population, they have a lower rate of those attacks per-capita because they have put rules in place to be less of a soft target.
- a4isms 1y ago
  I think everything you're saying about the difference between school shootings and NPM supply chain attacks is correct, but at the same time "You made a joke about why A is like B, but here's why A and B are actually different, therefore the joke is not funny" is not persuasive. Comedy does not need to be rigorous, the person you're replying to is not arguing that supply chain attacks are like school shootings, therefore open source programmers should do active shooter drills. That would be fallacious reasoning. It's literally just a joke. If it tickles your fancy, it works for you. If you get lost in the weeds of comparing the socio-political mechanisms of open source to guns, or note that supply chain attacks happen to other package managers, the joke won't work for you. I assure you, it works just fine for me even though yes I think it would be ridiculous to claim there's anything more to the comparison than, "This thing keeps happening, nobody thinks doing anything about it is worth the bother, so look at that, it keeps happening."
  - acdha 1y ago
    I chuckled, too, but I’m a Python developer and it’s not like this doesn’t happen there either. If you want the shorter version: “laugh after you’ve hardened your update process”.
TZubiri 1y ago
"The issue is actually lack of guns, the way way to prevent this is by having more guns" kind of doubling down. The issue is the people that use npm, and choose to have 48 layers of dependencies without paying for anything. Blaming microsoft, which is a company which pays engineers and audits all of its code and dependencies, is a step in the wrong direction in the necessary self reflection path off npm vulns.
smithkl42 1y ago
Among other things, the attack space for npm is just so much larger. We run a large C# codebase (1M+ LOC) and a somewhat smaller TypeScript codebase (~200K LOC). I did a check the other day, and we have one potentially vulnerable nuget dependency for every 10,000 lines of C# code, but one potentially vulnerable npm dependency for about every 115 lines of TS code.

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

a4isms 1y ago

Deeply underrated comment. You can peel back the layers of sarcasm like... An onion.

deleted 1y ago
[deleted]
TZubiri 1y ago
Btw, it's copypasta at this stage
- a4isms 1y ago
  Anyone familiar with The Onion knows this, The Onion themselves repost the exact same thing every time there's a school shooting. Which emphasizes how regularly it happens, and therefore in turn I have no objection to a joke like this becoming copy pasta every time an NPM supply chain attack takes place. https://duckduckgo.com/?q=site%3Atheonion.com+%22no+way+to+prevent+this%22 https://duckduckgo.com/?q=site%3Atheonion.com+%22no+way+to+p...

andrewl-hn 1y ago

TBF it does happen to other package managers, too. There were similar attacks on PyPI and Rubygems (and maybe others). However, since npm is the largest one and has the most packages released, updated, and downloaded, it became the primary target. Similar to how computer viruses used to target Windows first and foremost due to its popularity. Also, smaller package managers tend to learn from these attacks on npm, and by the time the malware authors try to use similar types of attacks on them the registries already have mitigations in place.

shakna 1y ago
PyPI is working towards attestation [0], and already has "Trusted Publisher" [1]. Ruby has had signed gems since v2 [2]. These aren't a panacea. But they do mean an effort has been made. npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4] I don't think it's fair to compare npm to the others. [0] https://docs.pypi.org/attestations/producing-attestations/ https://docs.pypi.org/attestations/producing-attestations/ [1] https://docs.pypi.org/trusted-publishers/ https://docs.pypi.org/trusted-publishers/ [2] https://docs.ruby-lang.org/en/master/Gem/Security.html https://docs.ruby-lang.org/en/master/Gem/Security.html [3] https://github.com/npm/npm/pull/4016 https://github.com/npm/npm/pull/4016 [4] https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29
- madeofpalk 1y ago
  NPM has both Trusted Publishing and provenance claims for where packages are built. https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/generating-provenance-statements https://docs.npmjs.com/generating-provenance-statements Trusted Publishing is relatively new - GA-ed in July https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/ https://github.blog/changelog/2025-07-31-npm-trusted-publish...
  - otterley 1y ago
    Trusted Publishing is a marketing term—a fancy name for OIDC support and temporary auth token issuance. It delegates authenticating the uploader to their identity provider, nothing more. In a very real sense, it shifts responsibility to someone else. For example, if the uploader was using Google as their identity provider and their Google account was popped, the attacker would be able to impersonate the uploader. So I wouldn’t describe it as establishing a strong trust relationship with the uploader. It only meaningfully improves the security of the NPM ecosystem if (a) everyone is forced to sign packages and (b) identity providers require more secure authentication methods with as hardware tokens or passkeys.
  - 1y ago

h1fra 1y ago

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

izacus 1y ago
What about Java's Maven, much more popular and longer living?
- simonw 1y ago
  What makes you think Maven is more popular?
- rs186 1y ago
  When your only dependencies are Spring and Apache Commons, which requires legal approval in your corporation to use, and each update requires scrutiny, it's hard to get any supply chain attacks, right?
amiga386 1y ago
As far as I remember: "go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run) Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u" You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher would get pwned while working on something unrelated. The Go community tends not to "micropublish" so fewer people have or need commit rights to published go modules. Go has a decent standard library so there are fewer "missing core functionality" third-party packages that world + dog depends on. Npm is easier to pwn than Go, Maven, RubyGems, PyPI, CPAN, etc. because the design has more footguns and its community likes it that way
- h1fra 1y ago
  postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.

acdha 1y ago

This is funny but ultimately a mischaracterization of a popularity contest. Node culture is extreme–perhaps pathological–about using many dependencies to work around the limited standard library but the same kind of attacks happen everywhere people are releasing code. The underlying problem is that once you release something it takes only seconds before someone else can be running your code with full privileges to access their account. That’s why the joke doesn’t really work: America is a huge outlier for gun violence because we lack structural protections. Australia doesn’t have fewer attacks in proportion to a smaller population, they have a lower rate of those attacks per-capita because they have put rules in place to be less of a soft target.

a4isms 1y ago
I think everything you're saying about the difference between school shootings and NPM supply chain attacks is correct, but at the same time "You made a joke about why A is like B, but here's why A and B are actually different, therefore the joke is not funny" is not persuasive. Comedy does not need to be rigorous, the person you're replying to is not arguing that supply chain attacks are like school shootings, therefore open source programmers should do active shooter drills. That would be fallacious reasoning. It's literally just a joke. If it tickles your fancy, it works for you. If you get lost in the weeds of comparing the socio-political mechanisms of open source to guns, or note that supply chain attacks happen to other package managers, the joke won't work for you. I assure you, it works just fine for me even though yes I think it would be ridiculous to claim there's anything more to the comparison than, "This thing keeps happening, nobody thinks doing anything about it is worth the bother, so look at that, it keeps happening."
- acdha 1y ago
  I chuckled, too, but I’m a Python developer and it’s not like this doesn’t happen there either. If you want the shorter version: “laugh after you’ve hardened your update process”.

TZubiri 1y ago

"The issue is actually lack of guns, the way way to prevent this is by having more guns" kind of doubling down. The issue is the people that use npm, and choose to have 48 layers of dependencies without paying for anything. Blaming microsoft, which is a company which pays engineers and audits all of its code and dependencies, is a step in the wrong direction in the necessary self reflection path off npm vulns.

smithkl42 1y ago

Among other things, the attack space for npm is just so much larger. We run a large C# codebase (1M+ LOC) and a somewhat smaller TypeScript codebase (~200K LOC). I did a check the other day, and we have one potentially vulnerable nuget dependency for every 10,000 lines of C# code, but one potentially vulnerable npm dependency for about every 115 lines of TS code.