'No way to prevent this,' says only package manager where this regularly happens • Hacker News Board

Re: 'No way to prevent this,' says only package manager where this regularly happens

#41

Post by est31 » Sat, May 16, 2026, 2:18 AM UTC

nothinkjustai wrote: post #29

lostglass wrote: post #26

Earlier quoted context omitted.

To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.

Rust doesn’t have post install scripts

There is build.rs, proc macros are unsandboxed, and lastly you install the binary so that you can run it. Even if the build and install were fully sandboxed, the binary could still do malicious stuff if ran.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#42

Post by raggi » Sat, May 16, 2026, 2:20 AM UTC

Gigachad wrote: post #17

exabrial wrote: post #10

I really don't understand why the npm project cannot embrace PGP as an ambulatory 'good enough' solution.

Would that help? Most of these recent attacks, the attackers have gained access to the system that builds the packages. So it would have just signed the malicious build the same.

nope, doesn't help. signatures and removal of script points have zero net effect on the value of the target that the ecosystem has, or how easy/hard it is to write a worm. the package code gets run, this is statistically true, and the exploited developers/environments will sign packages, this is also statistically true.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#43

Post by raggi » Sat, May 16, 2026, 2:21 AM UTC

yegle wrote: post #27

Vendorizing using git submodule should be a robust mitigation for this problem.

subtree is better for this case, you want to encourage actual reading before running. reading won't catch everything but it catches a lot, and the burden isn't as high as people always complain about before they try it.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#44

Post by eulgro » Sat, May 16, 2026, 2:23 AM UTC

These satire articles on cybersecurity are really entertaining.

The other one a few days ago was also good: https://nesbitt.io/2026/02/03/incident-report-cve-2024-yikes...

Re: 'No way to prevent this,' says only package manager where this regularly happens

#45

Post by nirvdrum » Sat, May 16, 2026, 2:25 AM UTC

aselimov3 wrote: post #8

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but it often means they're pulling in more code than they need. The JS ecosystem has also favored smaller modules, so you need many of them. And everyone builds on top of that, leading to massive growth in dependency graphs. It's a huge surface area for things to go wrong, intentionally or not.

With many other languages, you have a lot of functionality out of the box. Certainly, there have been bugs and security issues, but they're a drop in the bucket compared to what you see in the JS ecosystem. With other languages, you have a much smaller external dependency graph and the core functionality is coming from a trusted 3rd party.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#46

Post by nine_k » Sat, May 16, 2026, 2:26 AM UTC

827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

...and only if you invoke it with --dangerously-run-postinstall-scripts; otherwise it will report an error if a postinstall script is found.

This is definitely going to affect any packages that need to link to native code and/or compile shims, but these are very few.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#47

Post by apothegm » Sat, May 16, 2026, 2:28 AM UTC

nirvdrum wrote: post #45

aselimov3 wrote: post #8

What are the actual guarantees that go/Rust make that Python/npm don’t? It seems like it might just be that Python/npm are juicier targets? I’m starting to try and avoid all third party packages

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but i…

Why Python, tho, in that case? Its stdlib is quite robust. Surprisingly so in some areas.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#48

Post by throwaway27448 » Sat, May 16, 2026, 2:31 AM UTC

raggi wrote: post #39

827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

Surely every layer of defense in depth is a distraction except the one that prevents the problem.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#49

Post by piperswe » Sat, May 16, 2026, 2:31 AM UTC

raggi wrote: post #39

827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

A lot of it ends up bundled to run in a browser though, and doesn't end up running in Node.js

Re: 'No way to prevent this,' says only package manager where this regularly happens

#50

Post by guidedlight » Sat, May 16, 2026, 2:32 AM UTC

827a wrote: post #30

There is no legitimate reason why postinstall scripts need to exist. The npm team needs to grow up and declare "starting with npm version whatever, npm will only run postinstall scripts for versions of packages published before ${today}".

Security issues aside, they are a nightmare in enterprise environments where internet and OS access is heavily restricted.