Upcoming breaking changes for npm v12

21 points by Jackevansevo

Gaelan

I've always found the emphasis on preinstall scripts (and their equivalents in other package managers) to be a bit silly - after all, the whole point of a package manager is to install arbitrary code. Even if npm install doesn't immediately run the code it downloaded, the next command you invoke after that probably will.

Admittedly, for a JavaScript package manager, this makes slightly more sense because some of the code the package manager installs might be destined to run in a browser, not the developer's machine. But:

Plenty of server-side JavaScript projects exist, especially now with server-side rendering being all the rage.
Even for client-only codebases, often the build tooling pulls in a package ecosystem as big or bigger than the production code.
Shipping malicious JavaScript in your website is also very bad.

Ultimately my view is that preinstall scripts are currently the path of least resistance for weaponizing a package compromise, so we currently see loads of them. (And as an individual, disabling preinstall scripts is perhaps a prudent defense, because you don't have to outrun the bear, just everyone else who gets exploited more easily than you.) But disabling preinstall scripts for everyone won't have a massive effect on the prevalence of supply chain attacks, it'll just move where in the package the malicious code goes.

bakkot
I largely agree but I still like this change as a reduction in attack surface, even if it's only a relatively minor such reduction. Some other positives:
- This also removes from the attack surface any packages which are required but never imported, e.g. because they're providing functionality which you aren't using. ESM semantics make this trickier (because imports have to be at the top level unless you want to make them all async, unlike require which could trivially be called only on the paths where it's used), but the import defer proposal will someday help address that.
- More speculatively, I would like to live in a world where individual dependencies are properly sandboxed, or at least limited in what they are allowed to import. JavaScript is pretty well suited for this - no poking at the machine internals like in Java or C (or, well, only poking at some machine internals, but that can be locked down too). This is a necessary-but-not-sufficient path on the step towards that world.
colonelpanic

the whole point of a package manager is to install arbitrary code. Even if npm install doesn't immediately run the code it downloaded, the next command you invoke after that probably will.

I think it's fair to see this not as solving the problem of these attacks, but rather shifting the blame. It's a big, click-wrap "Agree" button that you must press that absolves NPM of responsibility.