←back to thread

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

(socket.dev)
1208 points jamesberthoty | 1 comments | 16 Sep 25 11:22 UTC | HN request time: 0.718s | source
Show context
theodorejb ◴[16 Sep 25 15:07 UTC] No.45263347[source]▶
It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies.

This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package is actually imported in a browser or other production environment.

replies(3): >>45263672 #>>45269128 #>>45273686 #
notatallshaw ◴[16 Sep 25 15:34 UTC] No.45263672[source]▶
Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts...

What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands?

I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.

replies(1): >>45263931 #
1. theodorejb ◴[16 Sep 25 15:53 UTC] No.45263931[source]▶
In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.