Hacker News new | ask | show | jobs
by jonkoops 29 days ago
Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2].

1. https://pnpm.io/settings#allowbuilds

2. https://pnpm.io/cli/approve-builds

2 comments

After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
> Made me wonder why the packages even need build scripts

As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2.

Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.

> Made me wonder why the packages even need build scripts.

Historically it was to accommodate packages like the original SASS compiler:

https://sass-lang.com/ruby-sass/

Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.

Agree. Postinstall scripts should be explicit opt-in, not ambient capability.

Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review.

The default should probably be: install files, don’t run code.

If postinstall scripts are restricted the people behind these attacks will switch to something else. Package code is executed automatically by Node when imported, which could be a good replacement. It'll probably run when tests run instead but it's still going to run for most people.
Limiting post install as an attack vector is still a good thing.

Node is working on a similar permission model to Deno that allows explicitly granting certain system resource permissions https://nodejs.org/api/permissions.html. Using it should help reduce impact from malicious code, though if you allow wide permissions it's unlikely to help.

> Limiting post install as an attack vector is still a good thing.

If npm got rid of the post install scripts it would permanently break the install process of packages that use it. Affected systems will need to bypass it, stay on an old npm version, or upgrade the packages to versions that work without post install. Meanwhile, attackers switch to a different attack vector and continue.

Who does that help?

I said limit post install, not remove them. Having an allow list in package.json of packages which can run post install would work fine. Pnpm already does this.

Having said that I'm not against full on removal of post install either. It would get more pushback, but would still be possible for people to manually run the post install for the few packages that require it, or to add them as a script in package.json.