Comment by raggi
4 hours ago
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.
The installed code may be run in different settings, under a different user, with different privileges. Say, it may not run in CI/CD at all, or run only with the test user's privileges.
Postinstall scripts run at install time, with installer's privileges.
A lot of it ends up bundled to run in a browser though, and doesn't end up running in Node.js
> There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of privileged access to your cloud environment; deployed services are more likely to be highly scoped). But, better in some ways.
> Compromised code probably won't (maybe it will if your test cases test a compromised package).
Code runs automatically on import, you don't have to call dependency.infectMePlease()
Your code imports depA which imports depB which imports depC which imports depD which has been compromised, and boom, malicious code runs before you've even finished resolving the imports.
> your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm
I've never once seen or worked with a CI pipeline that ran "npm install" that would be any safer if post-install scripts didn't exist. They all run "npm run test" or similar.
Surely every layer of defense in depth is a distraction except the one that prevents the problem.
It's not defense in depth if the mechanism is trivially bypassed.