Should we block lifecycle script of dependencies during installation?

[zkochan]

There was recently an incident with rspack, where it was published with a postinstall script that contained malware. Such incidents happen from time to time, so it could be a good idea to stop running the scripts of dependencies by default, starting from pnpm v10.

Prior art: bun already blocks the scripts of dependencies (unless they are from a "trusted list"). We won't have a default trusted list.

[KSXGitHub]

I think this is a good idea for other package managers as well as it would help reduce the threat of supply chain attack.

[WilcoSp]

maybe add a command that can list which dependencies have a post install script to so that if a dependency needs it could be added to the allowlist

[zkochan]

Pnpm lists such deps in the install summary. We can add a command later.

[WilcoSp]

@zkochan it would still be nice to have it as it could be a child dependecy of a dependency like for example Vue-demi for Pinia & @vueuse/core

[zkochan]

We will have such command but we print all the deps in the summary. Deps of deps too if they had skipped postinstalls.

[bozdoz]

Not sure that a trusted list would have stopped something like rspack (someone probably would have trusted it to run install scripts).
Maybe you could have a trusted author/library list but also a trusted commands list (might catch issues where the install scripts change).

[zkochan]

They didn't have a postinstall prior to the attack, so users would have to add them to the allow list. Sure, some would add them to the list without inspection

[naugtur]

socket.dev does the inspection, so no excuses. 😉

But in case they had a script that was initially allowed, the way to keep it secure would be to ensure it's not undergone meaningful changes from when it was allowed first.
That's extremely difficult to pull off if you assume malicious intent, because the script could remain unchanged while using a dependency that gets bumped to a malicious version.
So as long as you trust a package to run scripts already there's not much that can be done.
Speaking from @lavamoat/allow-scripts experience.

[WilcoSp]

maybe also add to the lock file a checksum of the postinstall script (maybe also with js and other executable files) so that it's easier to spot if something isn't correct

[zkochan]

That might be a good idea but the postinstall file could reference some other file that gets updated with malware later on. So unless we can calculate a checksum for the "bundled" install script, it could be a misleading layer of security

[johnnyreilly]

My instinctive preference is "no" as it would block functionality like this which unzips in a postinstall step:

https://johnnyreilly.com/smuggling-gitignore-npmrc-in-npm-packages

That said, I understand the rationale. Would there be a way to allow a postinstall for dependencies you trust? That way instructions could be put in a README to pnpm install package-with-lifecycle-scripts --allow-lifecycle or similar and at least there's a means to opt in.

As long as there's a way to opt in it's probably fine. I guess the issue is if there isn't, then a whole class of packages stop being compatible with pnpm

[KSXGitHub]

This poll is only about default behavior. You can always define either onlyBuiltDependencies or neverBuiltDependencies to enable/disable scripts for certain packages.

[KSXGitHub]

That being said, I wonder what are the most common effects packages often want to achieve by using lifecycle scripts? Maybe NPM itself should standardize and handle these behaviors so that users may rely less on scripts. For example, fetching and unpacking archives could be done without scripts if NPM allows them in dependencies field.

[naugtur]

@johnnyreilly you could have used a recursive rename it moved the unpacking to the runtime of your cli.
With a lifecycle script you're preventing your users from disabling the feature used in delivery of the cast majority of npm malware and adding to the "don't make it secure by default" arguments pile.

Your particular lifecycle script is not necessary as opposed to node native packages where a build needs to happen before the actual package gets required in the process.

[naugtur]

That being said, I wonder what are the most common effects packages often want to achieve by using lifecycle scripts? Maybe NPM itself should standardize and handle these behaviors so that users may rely less on scripts. For example, fetching and unpacking archives could be done without scripts if NPM allows them in dependencies field.

I remember it was brought up in npm RFC meetings and someone was working on more specific alternatives to all usecases so that there's a migration for all before scripts get turned off. That was the official response while Darcy was there. I'm not sure a list of usecases exists somewhere we could look it up.
Another issue was they were worried legitimate use of install scripts is common among old unmaintained packages that won't update to whatever new thing.

[vorant94]

Just to add another use case of useful post install scripts

Installing TS lib from GitHub directly, post install script runs compilation and there you go

Very nice, when you instead of waiting for release of fix, can directly use upstream version

[zkochan]

Yeah, I think this will still work.

[naugtur]

A separate config to disable it to would be nice. Got dependencies are already super painful for security and no PKG manager is offering good config around hiw they work.

Not to mention how GitHub let's you install from a fork without realizing it
https://bsky.app/profile/naugtur.pl/post/3lcuwnotzqd2f

[zkochan]

Git-hosted dependencies are a time-bomb for sure. I think what we could do is allowing the build of direct git-hosted dependencies but requiring users to specifically list what git-hosted packages are allowed to be installed in subdependencies.

[naugtur]

For the record:
LavaMoat is happy to contribute whatever you find useful in
https://www.npmjs.com/package/@lavamoat/allow-scripts

Would be great to share the allowlist format.

The way the allowlist identifies the packages has to avoid being tricked with bundled dependencies and git/url installs having the same name in their package.json
We're dealing with it by identifying packages with their position in dependency tree. As a package manager you might be able to do more.

[zkochan]

If you can publish a package that will have a json file with the list of package names, then pnpm users will be able to use that allowlist in their projects.