[FEATURE] opt-in install and postinstall scripts

[koba04]

What / Why

install and postinstall are npm scripts that run while npm install ${package} or npm ci.
It means that we allow the package author to run any scripts on our machine, which is definitely dangerous if we don't recognize what packages are installed as dependencies.
Unfortunately, it might be impossible to recognize all the dependencies on your project so we run scripts we don't know while npm install.

To avoid this, we can use the --ignore-scripts option, which disables all npm scripts while installing dependencies.
But sometimes the scripts are required to work the packages.

I've created an npm package to print all these scripts in your project.
https://github.com/koba04/install-scripts

But I think it would be nice if npm has the mechanism to opt-in install and postinstall scripts.
I guess there are some ways to do this. The followings are ideas on me. Please let me know If you have any ideas 🙏

allowedScripts in package.json

This field is to allow packages to run npm scripts.
With this option, we can share the information that we allow packages to run scripts through the package.json.
It might be better this option is enabled only with --allowed-scripts option.

{
  "allowedScripts": {
    "fsevents": "^1.0.0",
    "puppeteer": "*"
  }
}

--confirm-scripts

This option is to show a prompt whether you run the script or not.
This is useful if you know what the script would do.

Do you run the install script for fsevents?
y/n

other option

This is another feature request for --ignore-scripts.
I hope that npm prints all scripts not to run while installing with --ignore-scripts like https://github.com/koba04/install-scripts.

When

• npm install or npm ci

Where

• npm public registry

How

Current Behavior

• run all install and postinstall scripts or don't run any scripts with --ignore-scripts option.

Expected Behavior

• We can opt-in scripts to be able to run.

Who

• n/a

References

• globally-installed package overwrites an existing binary in the target install location yarnpkg/yarn#7761

[koba04]

Yarn v2 has a similar feature using dependenciesMeta.
https://dev.to/arcanis/introducing-yarn-2-4eh1#perpackage-build-configuration

[DanielRuf]

We should go from a "allow everything by default" to a "deny everything by default" to protect most developers against such attacks with pkg.scripts by default. See also my comment regarding hashes (strict mode, that's something that I would like to use).

Because so far the registry is way too big, no releases are actively checked (I did some experiments in the past and reuploaded disabled malware that was was accidentally found by Sonatype and removed by npm after 8 months, see https://blog.sonatype.com/nexus-intelligence-insights-sonatype-2018-0413) by npm / GitHub, no access for threat hunters to run YARA rules on the package corpus, ... =(

[DanielRuf]

{
  "whitelistScripts": [
    "fsevents",
    "puppeteer"
  ]
}

I would like to see some solution like hashes for scripts (only hash pkg.scripts as text). Otherwise these could be weaponized in the future and the scripts could be changed to deliver malware. See how Comodo, Zonealarm and others did this (strict whitelist, based on hashes / data).

Something similar like the SRI hashes in browsers. People also wanted this feature in Deno but it looks like it was never implemented: denoland/deno#200

[DanielRuf]

Another recommendation: please enforce 2FA for all my packages when I setup 2FA for my npm account. I have to do this manually for every single package.

[sandstrom]

I'm guessing this would help against npm packages executed only in the browser.

But for packages running in node, they still have disk access + can execute on the shell, no? So in that later case shutting down scripts wouldn't help much?

[ljharb]

@cmdcolin i'm pretty sure that in fact is a very, very low proportion. The vast majority of JS packages on npm works universally, in my experience.

[cmdcolin]

sure. I guess I am likely wrong in that sense. I guess I mean to say that I, as a web dev would not be running many of the packages I am installing under node

[koba04]

But for packages running in node, they still have disk access + can execute on the shell, no? So in that later case shutting down scripts wouldn't help much?

Yes, they can execute any scripts when they are used as require("some-package"), so security issues are still remained. But this is often used as an attack vector and install scripts are more dangerous than the case because this allows all installed packages to run any scripts without using them. In this case, typing the wrong package name also causes serious issues because it gives permissions to run arbitrary scripts to un-intentional packages.

[aggregate1166877]

But for packages running in node, they still have disk access + can execute on the shell, no? So in that later case shutting down scripts wouldn't help much?

Sure my staging / production servers would still be affected, but my CI/CD server would be protected because it just bundles things (I do unit tests in sandboxed containers). This means that all other products on my CI/CD servers are unaffected. As it stands now, if a single package needs install scripts and gets infected with malware, my entire CI/CD pipeline for all my products gets taken down indefinitely while I look for malicious processes.

[pmoleri]

@sandstrom your concerns are valid, but this RFC is about npm running non-sandboxed scripts on package installation, while what you describe is an node limitation, that as DanielRuf mentioned , will be covered by node.
What I want to say is that I wouldn't want to see this great proposal delayed by this argument.

[koba04]

#488 is another proposal related to this. It changes the default behavior of install scripts.

Note that I've updated the whitelistScripts field from an array to an object to be able to specify versions.

[DanielRuf]

to an object to be able to specify versions

Very good idea. As packages on the registry can not be changed after they are uploaded / published, this sounds like a good way to pin the allowed scripts to specific versions. But the content of the scripts and new scripts still have to be checked by the users then, but this is another issue.

[felipeplets]

For semantic reasons I would recommend the usage of allowlist over whitelist

Thanks for the RFC @koba04
@DanielRuf I second your thoughts on going from allow to deny by default.

[koba04]

Thank you! I've updated the usage in RFC.

[mohe2015]

Maybe just allowedScripts?