Support providing onlyBuiltDependencies list in a separate JSON file

[TravisJRyan]

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

As a developer in an enterprise setting, I want to maintain a list of approved dependencies for the onlyBuiltDependencies feature, but this only seems to be supported by a field in package.json. I think this would be fine if the user wants to override the environment, but it would be nice from a security perspective to default all users in an environment to a known list of dependencies that can run scripts.

Let me know if this is already feasible in some form.

Describe the solution you'd like

It would be great if npmrc (or some similar solution that is environment specific) can be given the onlyBuiltDependencies config that functions the same as the package.json field, but package.json would take priority if this is set.

Describe the drawbacks of your solution

• The same attribute can be specified in 2 places, which could lead to confusion as to which is taking precedence or why it's not working as expected in some cases.
• Managing this in an enterprise setting creates some things to be careful about: being thoughtful about the maintained list of dependencies, thinking about how this will change over time. It's simpler to leave this in package.json.

Describe alternatives you've considered

The simpler but more tedious alternative is just informing users in an enterprise environment to update their package.json (or automating this in some way) to use the config.

[zkochan]

Here's an idea. The dependencies are built when they are all linked to node_modules. Hence, we could load the onlyBuiltDependencies list from a dependency. You could publish a package with a json file, call it something like @comp/only-built-deps and add it to dev dependencies. Then some setting would set a path to the json file:

{
  "pnpm": {
    "onlyBuiltDependenciesFile": "./node_modules/@comp/only-built-deps/list.json"
  }
}

[TravisJRyan]

Hi @zkochan ,

This sounds great. One more thought - would it be possible for this to be additive with onlyBuiltDependencies? So there could be some default list from onlyBuiltDependenciesFile and then the user can add additional dependencies with onlyBuiltDependencies?

[zkochan]

Yes, I think it can be additive.

[Bessonov]

@zkochan I'm not sure if I'm missing something. From a security point of view, what's the difference between using the postinstall lifecycle hook and executing/spawning inside the dependency?

[gluxon]

From a security point of view, what's the difference between using the postinstall lifecycle hook and executing/spawning inside the dependency?

Is your question pertaining to whether the concept of onlyBuiltDependencies is necessary when dependencies can call exec/spawn methods from the Node.js child_process module? Am I interpreting the question correctly?

If so, there's a few significant differences:

1. NPM packages are used for other runtimes than Node.js as well. In a few other runtimes, arbitrary access to a developer's system aren't allowed.
   • For example, running Webpack in development mode against a website is not expected to pwn your system. The exec and spawn methods from a dependency would simply fail in a web environment, but would succeed in a postinstall script.
   • Deno is a newer runtime that focuses on no file system access by default. Postinstall scripts circumvent that entirely.
2. On CI/CD builds, postinstall scripts can modify the source code of your application while it's being packaged. For example, you could set up a simple "compile" job that runs pnpm install and then tsc. The postinstall script could modify source code in ways that simply import/require'ing the dependency at runtime could not.

[Bessonov]

@gluxon Yes, that is precisely the question. Thanks for clarifying! While it doesn't address the issue with the node, I understand your point!

[gluxon]

Glad it helped! It's a good question. 🙂

[zkochan]

🚢 8.9.0

[TravisJRyan]

Thanks for the quick follow up!

[zkochan]

@Bessonov actually I had the same questions as you and I even tweeted about it. Brandon answered you well. One additional case would be when someone makes a typo in the package name and installs malware.

[Bessonov]

@zkochan Thank you! This is indeed a good point too. The only thing I am still concerned about is that when configuring, for example, file system access, we don't specify "dependency x can read folder/file y", but rather, we grant the entire project access to folder/file y, at least in Deno. This certainly limits the attack surface to a significant extent, but it falls short of being a bulletproof solution. On the other hand, I must acknowledge that passing environment variables with access to S3 faces a similar issue.