Hacker News new | past | comments | ask | show | jobs | submit
At this point, any package adding a pre-install hook where there previously was not one should be denied and treated with extreme suspicion.

It's time pre-install / post-install hooks were killed off. Start with a moratorium on any new ones.

yeah but they can just put the dropper, etc in index.js, so that it runs at import time rather than at install time, no? i guess first-install time is often a privileged developer machine, and will execute in a "server"-like runtime such as Node, Bun, Deno. but blocking preinstall scripts is basic first aid...
loading story #49169538
loading story #49170079
loading story #49169927
iirc does pnpm not allow them by default. But even if we killed them off there would still be a chance of the malware hooking into something else or only working in cli applications.
loading story #49171890
loading story #49171612
You'll just end up with people running `./configure` scripts or whatever instead. The solution I've currently landed on is:

1. Audit build scripts/ proc macros for rust code (and mark with cargo-vet).

2. Have an isolated workflow for "build/test/push artifact to temporary place" (s3, github artifact, whatever). No API keys in this workflow.

3. Have another workflow that has the API keys to publish that grabs the artifact and then places it into a registry.

This creates clear separation of "code runs here" and "environment has privileges".

In my own slop-driven programming language I have build scripts declare their capabilities upfront so that you can statically reason about them (same with runtime permissions).