[ImPostingOnHN]

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as.

It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed it somewhere where it would be dynamically loaded all the time.

[bandrami]

That's why we don't let the developers run system package manager install scripts as root. We do let them run npm inside containers, which is still more access than I'd like them to have.

[icedchai]

Is this one of those places where it takes 6 to 12 weeks to get something new installed on your machine?

[bandrami]

You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.

[icedchai]

Interesting. How about in a container? What industry is this, just curious?

[bandrami]

Defense. Containers on our normal network are the wild west, but anything that touches the secure network has to be signed off on by the clients.

[skydhash]

I think it’s just a bundle of issues. Deep graph of dependencies, distribution of minimized code (java has jars, but I don’t remember scripts), and nearly impossible to audit. With most projects in other ecosytems, you only have to interact with a few developer/orgs. But with npm, you add one library and you need to essentially trust 10s of entities on the internet.

[jdiff]

Most package managers with postinstall scripts are also heavily curated and have reputation systems. As you say, they run as root, so the high trust requirement is definitely warranted. Anyone can upload an npm package.

[TylerE]

Nearly every package manager I've ever used had post-install scripts.

You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs. This worm spreads because npm install runs arbitrary scripts as you, automatically, just from resolving the tree. You don't have to build it, run it, or even import it. Opening the project in an IDE is enough. apt/dnf scripts run on packages a maintainer signed and a distro gatekept. Not on whatever some rando pushed to a public scope 20 minutes ago that landed in your lockfile six levels deep. "They both technically execute code" is true and beside the point. One runs signed code from a trusted path, the other runs unsigned code from the default automated path. That's the whole ballgame.

[ImPostingOnHN]

> You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs.

> You don't have to build it, run it, or even import it

If you just installed something with npm, chances are you'll be running it shortly, either as a tool or a library, probably minutes or seconds later. I imagine the use case of installing an npm package you don't plan on using or transitively importing, constitute a small portion of npm installs.

[ChocolateGod]

> apt/dnf scripts run on packages a maintainer signed and a distro gatekept

Unfortunately apt/dnf isn't much better here because random tutorials online suggest people add random repositories where the creator of any repository effectively has root access to anyone machine that adds it as a remote.

[Zardoz84]

It's the exact same problem when random tutorials (and official pages) recommend to do a curl "URL" | bash to install something. Every time that I see it, I look it suspicious.

[orphea]

Don't add random repositories from random tutorials? Come on, it's basic Internet hygiene. Entirely different thing.