[darkamaul]

> We do not run postinstall scripts. This prevents packages from executing arbitrary code during installation.

I get the intent, but I’m not sure this really buys much. If a package is compromised, the whole thing is already untrustworthy and skipping postinstall doesn’t suddenly make the rest of the code safe. If it isn’t compromised, then you risk breaking legitimate installation steps.

From a security perspective, it feels like an odd tradeoff. I don’t have hard data, but I’d wager we see far more vulnerabilities patched through regular updates than actual supply-chain compromises. Delaying or blocking updates in general tends to increase your exposure rather than reduce it.

[mnahkies]

I agree but there's a bit of nuance here. Today scanning steps typically happen post install, which is wild but the status quo. Therefore preventing anything from running during install is desirable.

I'd like to see the ability to scan/restrict as part of the installation step become popular, there are some proprietary tools that do this already but it's not yet a common capability.

[MetaWhirledPeas]

Yes. For instance when we had that crypto malware npm fiasco a few days back I happened to be updating one of my packages. The audit lit up with dozens of critical issues, but of course this was after it installed everything. Luckily I had disabled install scripts so it became a matter of not running the code until I could get it reverted back.

[jcgl]

It does protect the build machine though. Seems like quality, low-hanging security fruit to me. If I want to casually hack on some random web app, I don’t have to worry about giving arbitrary scripts running from the ~4 gazillion dependencies.