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.
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.
Trusted publishing helps with tracking down how something got compromised after compromise. It doesn't do anything to protect against compromise except for using time-limited credentials but that only makes the window smaller. It doesn't make compromise impossible
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.
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."
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”.
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.
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.
"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.
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
"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
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.
I notice you didn't address the other 4 differences. All 5 are about "defence in depth", making things less likely - and conversely, not doing them makes pwning more likely.
I'll add a 6th difference: "go get" downloads source code, not maintainer-provided tarballs. You can't sneak extra things in there that aren't in the code repo.
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?
