chore(deps): update dependency pnpm to v9 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
pnpm (source)	^7.18.2 -> ^9.0.0

GitHub Vulnerability Alerts

CVE-2023-37478

Summary

It is possible to construct a tarball that, when installed via npm or parsed by the registry is safe, but when installed via pnpm is malicious, due to how pnpm parses tar archives.

Details

The TAR format is an append-only archive format, and as such, the specification for how to update a file is to add a new record to the end with the updated version of the file. This means that it is completely valid for an archive to contain multiple copies of, say, package.json, and the expected behavior when extracting is that all versions other than the last get ignored.

This is further complicated by that during tarball extraction, all package managers are configured to drop the first path component, so collisions can be created simply by using multiple root folders in the archive, even without performing updates.

When pnpm extracts a tar archive via tar-stream, it appears to extract only the first file of a given name and discards all subsequent files with the same name.

PoC

Create a root folder with the following layout:

• a/package.json
• package/package.json
• z/package.json

File contents:

a/package.json

{
    "name": "test-package",
    "version": "0.1.0",
    "description": "This is a bad version of a test package",
    "dependencies": {
        "react": "^15"
    }
}

package/package.json

{
    "name": "test-package",
    "version": "0.1.0",
    "description": "This is a bad version of a test package",
    "dependencies": {
        "react": "^16"
    }
}

z/package.json

{
    "name": "test-package",
    "version": "0.1.0",
    "description": "This is the good version of a test package",
    "dependencies": {
        "react": "^17"
    }
}

Then use the tar binary to produce a tarball (working directory is the root folder):
tar -c -z --format ustar -f package.tgz a package z
The order of the folders at the end matters; whichever one is last will end up being the package.json that wins when extracted by npm; the one that is first will be the one that wins when extracted by pnpm.

Install the tarball via the file: protocol.

Observe that with npm, the lockfile has react@17, while with pnpm it has react@15.

Impact

This can result in a package that appears safe on the npm registry or when installed via npm being replaced with a compromised or malicious version when installed via pnpm.

CVE-2024-53866

Summary

pnpm seems to mishandle overrides and global cache:

1. Overrides from one workspace leak into npm metadata saved in global cache
2. npm metadata from global cache affects other workspaces
3. installs by default don't revalidate the data (including on first lockfile generation)

This can make workspace A (even running with ignore-scripts=true) posion global cache and execute scripts in workspace B

Users generally expect ignore-scripts to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it).

Here, that expectation is broken

Details

See PoC.

In it, overrides from a single run of A get leaked into e.g. ~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json and persistently affect all other projects using the cache

PoC

Postinstall code used in PoC is benign and can be inspected in https://www.npmjs.com/package/ponyhooves?activeTab=code, it's just a console.log

1. Remove store and cache
   On mac: rm -rf ~/Library/Caches/pnpm ~/Library/pnpm/store
   This step is not required in general, but we'll be using a popular package for PoC that's likely cached
2. Create A/package.json:

   {
     "name": "A",
     "pnpm": { "overrides": { "rimraf>glob": "npm:ponyhooves@1" } },
     "dependencies": { "rimraf": "6.0.1" }
   }

   Install it with pnpm i --ignore-scripts (the flag is not required, but the point of the demo is to show that it doesn't help)
3. Create B/package.json:

   {
     "name": "B",
     "dependencies": { "rimraf": "6.0.1" }
   }

   Install it with pnpm i

Result:

Packages: +3
+++
Progress: resolved 3, reused 3, downloaded 0, added 3, done
node_modules/.pnpm/ponyhooves@1.0.1/node_modules/ponyhooves: Running postinstall script, done in 51ms

dependencies:
+ rimraf 6.0.1

Done in 1.4s

Also, that code got leaked into another project and it's lockfile now!

Impact

Global state integrity is lost via operations that one would expect to be secure, enabling subsequently running arbitrary code execution on installs

As a work-around, use separate cache and store dirs in each workspace

---

Release Notes

pnpm/pnpm (pnpm)

v9.15.0

Compare Source

v9.14.4

Compare Source

v9.14.3

Compare Source

v9.14.2

Compare Source

Patch Changes

• pnpm publish --json should work #​8788.

Platinum Sponsors

Gold Sponsors

v9.14.1

Compare Source

Minor Changes

• Added support for pnpm pack --json to print packed tarball and contents in JSON format #​8765.

Patch Changes

• pnpm exec should print a meaningful error message when no command is provided #​8752.
• pnpm setup should remove the CLI from the target location before moving the new binary #​8173.
• Fix ERR_PNPM_TARBALL_EXTRACT error while installing a dependency from GitHub having a slash in branch name #​7697.
• Don't crash if the use-node-version setting is used and the system has no Node.js installed #​8769.
• Convert settings in local .npmrc files to their correct types. For instance, child-concurrency should be a number, not a string #​5075.
• pnpm should fail if a project requires a different package manager even if manage-package-manager-versions is set to true.
• pnpm init should respect the --dir option #​8768.

Platinum Sponsors

Gold Sponsors

v9.14.0

Compare Source

v9.13.2: pnpm 9.13.2

Compare Source

Patch Changes

• Detection of circular peer dependencies should not crash with aliased dependencies #​8759. Fixes a regression introduced in the previous version.
• Fix race condition of symlink creations caused by multiple parallel dlx processes.

Platinum Sponsors

Gold Sponsors

Silver Sponsors

v9.13.1: pnpm 9.13.1

Compare Source

Patch Changes

• Fixed some edge cases where resolving circular peer dependencies caused a dead lock #​8720.

Platinum Sponsors

Gold Sponsors

Silver Sponsors

v9.13.0: pnpm 9.13

Compare Source

Minor Changes

• The self-update now accepts a version specifier to install a specific version of pnpm. E.g.:

  pnpm self-update 9.5.0
  

  or

  pnpm self-update next-10
  

Patch Changes

• Fix Cannot read properties of undefined (reading 'name') that is printed while trying to render the missing peer dependencies warning message #​8538.

Platinum Sponsors

Gold Sponsors

Silver Sponsors

v9.12.3

Compare Source

Patch Changes

• Don't purge node_modules, when typing "n" in the prompt that asks whether to remove node_modules before installation #​8655.
• Fix a bug causing pnpm to infinitely spawn itself when manage-package-manager-versions=true is set and the .tools directory is corrupt.
• Use crypto.hash, when available, for improved performance #​8629.
• Fixed a race condition in temporary file creation in the store by including worker thread ID in filename. Previously, multiple worker threads could attempt to use the same temporary file. Temporary files now include both process ID and thread ID for uniqueness #​8703.
• All commands should read settings from the package.json at the root of the workspace #​8667.
• When manage-package-manager-versions is set to true, errors spawning a self-managed version of pnpm will now be shown (instead of being silent).
• Pass the find command to npm, it is an alias for npm search

v9.12.2

Compare Source

Patch Changes

• When checking whether a file in the store has executable permissions, the new approach checks if at least one of the executable bits (owner, group, and others) is set to 1. Previously, a file was incorrectly considered executable only when all the executable bits were set to 1. This fix ensures that files with any executable permission, regardless of the user class, are now correctly identified as executable #​8546.

v9.12.1

Compare Source

Patch Changes

• pnpm update --latest should not update the automatically installed peer dependencies #​6657.
• pnpm publish should be able to publish from a local tarball #​7950.
• The pnpx command should work correctly on Windows, when pnpm is installed via the standalone installation script #​8608.
• Prevent EBUSY errors caused by creating symlinks in parallel dlx processes #​8604.
• Fix maximum call stack size exceeded error related to circular workspace dependencies #​8599.

v9.12.0

Compare Source

Minor Changes

• Fix peer dependency resolution dead lock #​8570. This change might change some of the keys in the snapshots field inside pnpm-lock.yaml but it should happen very rarely.

• pnpm outdated command supports now a --sort-by=name option for sorting outdated dependencies by package name #​8523.

• Added the ability for overrides to remove dependencies by specifying "-" as the field value #​8572. For example, to remove lodash from the dependencies, use this configuration in package.json:

  {
    "pnpm": {
      "overrides": {
        "lodash": "-"
      }
    }
  }

Patch Changes

• Fixed an issue where pnpm list --json pkg showed "private": false for a private package #​8519.
• Packages with libc that differ from pnpm.supportedArchitectures.libc are not downloaded #​7362.
• Prevent ENOENT errors caused by running store prune in parallel #​8586.
• Add issues alias to pnpm bugs #​8596.

v9.11.0

Compare Source

Minor Changes

• Experimental: added pnpm cache commands for inspecting the metadata cache #​8512.

Patch Changes

• Fix a regression in which pnpm deploy with node-linker=hoisted produces an empty node_modules directory #​6682.
• Don't print a warning when linking packages globally #​4761.
• pnpm deploy should work in workspace with shared-workspace-lockfile=false #​8475.

v9.10.0

Compare Source

Minor Changes

• Support for a new CLI flag, --exclude-peers, added to the list and why commands. When --exclude-peers is used, peer dependencies are not printed in the results, but dependencies of peer dependencies are still scanned #​8506.

• Added a new setting to package.json at pnpm.auditConfig.ignoreGhsas for ignoring vulnerabilities by their GHSA code #​6838.

  For instance:

  {
    "pnpm": {
      "auditConfig": {
        "ignoreGhsas": [
          "GHSA-42xw-2xvc-qx8m",
          "GHSA-4w2v-q235-vp99",
          "GHSA-cph5-m8f7-6c5x",
          "GHSA-vh95-rmgr-6w4m"
        ]
      }
    }
  }

Patch Changes

• Throw an exception if pnpm switches to the same version of itself.
• Reduce memory usage during peer dependencies resolution.

v9.9.0

Compare Source

Minor Changes

• Minor breaking change. This change might result in resolving your peer dependencies slightly differently but we don't expect it to introduce issues.

  We had to optimize how we resolve peer dependencies in order to fix some infinite loops and out-of-memory errors during peer dependencies resolution.

  When a peer dependency is a prod dependency somewhere in the dependency graph (with the same version), pnpm will resolve the peers of that peer dependency in the same way across the subgraph.

  For example, we have react-dom in the peer deps of the form and button packages. card has react-dom and react as regular dependencies and card is a dependency of form.

  These are the direct dependencies of our example project:

  form
  react@16
  react-dom@16
  

  These are the dependencies of card:

  button
  react@17
  react-dom@16
  

  When resolving peers, pnpm will not re-resolve react-dom for card, even though card shadows react@16 from the root with react@17. So, all 3 packages (form, card, and button) will use react-dom@16, which in turn uses react@16. form will use react@16, while card and button will use react@17.

  Before this optimization react-dom@16 was duplicated for the card, so that card and button would use a react-dom@16 instance that uses react@17.

  Before the change:

  form
  -> react-dom@16(react@16)
  -> react@16
  card
  -> react-dom@16(react@17)
  -> react@17
  button
  -> react-dom@16(react@17)
  -> react@17
  

  After the change

  form
  -> react-dom@16(react@16)
  -> react@16
  card
  -> react-dom@16(react@16)
  -> react@17
  button
  -> react-dom@16(react@16)
  -> react@17
  

Patch Changes

• pnpm deploy should write the node_modules/.modules.yaml to the node_modules directory within the deploy directory #​7731.
• Don't override a symlink in node_modules if it already points to the right location pnpm/symlink-dir#54.

v9.8.0

Compare Source

Minor Changes

• Added a new command for upgrading pnpm itself when it isn't managed by Corepack: pnpm self-update. This command will work, when pnpm was installed via the standalone script from the pnpm installation page #​8424.

  When executed in a project that has a packageManager field in its package.json file, pnpm will update its version in the packageManager field.

Patch Changes

• CLI tools installed in the root of the workspace should be added to the PATH, when running scripts and use-node-version is set.

• pnpm setup should never switch to another version of pnpm.

  This fixes installation with the standalone script from a directory that has a package.json with the packageManager field. pnpm was installing the version of pnpm specified in the packageManager field due to this issue.

• Ignore non-string value in the os, cpu, libc fields, which checking optional dependencies #​8431.

• Remember the state of edit dir, allow running pnpm patch-commit the second time without having to re-run pnpm patch.

v9.7.1

Compare Source

Patch Changes

• Fixed passing public-hoist-pattern and hoist-pattern via env variables #​8339.
• pnpm setup no longer creates Batch/Powershell scripts on Linux and macOS #​8418.
• When dlx uses cache, use the real directory path not the symlink to the cache #​8421.
• pnpm exec now supports executionEnv #​8356.
• Remove warnings for non-root pnpm field, add warnings for non-root pnpm subfields that aren't executionEnv #​8143.
• Replace semver in "peerDependency" with workspace protocol #​8355.
• Fix a bug in patch-commit in which relative path is rejected #​8405.
• Update Node.js in @pnpm/exe to v20.

v9.7.0

Compare Source

Minor Changes

• Added pnpm version management to pnpm. If the manage-package-manager-versions setting is set to true, pnpm will switch to the version specified in the packageManager field of package.json #​8363. This is the same field used by Corepack. Example:

  {
    "packageManager": "pnpm@9.3.0"
  }

• Added the ability to apply patch to all versions:
  If the key of pnpm.patchedDependencies is a package name without a version (e.g. pkg), pnpm will attempt to apply the patch to all versions of
  the package. Failures will be skipped.
  If it is a package name and an exact version (e.g. pkg@x.y.z), pnpm will attempt to apply the patch to that exact version only. Failures will
  cause pnpm to fail.

  If there's only one version of pkg installed, pnpm patch pkg and subsequent pnpm patch-commit $edit_dir will create an entry named pkg in
  pnpm.patchedDependencies. And pnpm will attempt to apply this patch to other versions of pkg in the future.

  If there are multiple versions of pkg installed, pnpm patch pkg will ask which version to edit and whether to attempt to apply the patch to all.
  If the user chooses to apply the patch to all, pnpm patch-commit $edit_dir would create a pkg entry in pnpm.patchedDependencies.
  If the user chooses not to apply the patch to all, pnpm patch-commit $edit_dir would create a pkg@x.y.z entry in pnpm.patchedDependencies with
  x.y.z being the version the user chose to edit.

  If the user runs pnpm patch pkg@x.y.z with x.y.z being the exact version of pkg that has been installed, pnpm patch-commit $edit_dir will always
  create a pkg@x.y.z entry in pnpm.patchedDependencies.

• Change the default edit dir location when running pnpm patch from a temporary directory to node_modules/.pnpm_patches/pkg[@​version] to allow the code editor to open the edit dir in the same file tree as the main project.

• Substitute environment variables in config keys #​6679.

Patch Changes

• pnpm install should run node-gyp rebuild if the project has a binding.gyp file even if the project doesn't have an install script #​8293.
• Print warnings to stderr #​8342.
• Peer dependencies of optional peer dependencies should be automatically installed #​8323.

v9.6.0

Compare Source

Minor Changes

• Support specifying node version (via pnpm.executionEnv.nodeVersion in package.json) for running lifecycle scripts per each package in a workspace #​6720.
• Overrides now support the catalogs: protocol #​8303.

Patch Changes

• The pnpm deploy command now supports the catalog: protocol #​8298.
• The pnpm outdated command now supports the catalog: protocol #​8304.
• Correct the error message when trying to run pnpm patch without node_modules/.modules.yaml #​8257.
• Silent reporting fixed with the pnpm exec command #​7608.
• Add registries information to the calculation of dlx cache hash #​8299.

v9.5.0

Compare Source

Minor Changes

• Added support for catalogs 8122.

  Catalogs may be declared in the pnpm-workspace.yaml file. For example:

v9.4.0

Compare Source

Minor Changes

• Some registries allow the exact same content to be published under different package names and/or versions. This breaks the validity checks of packages in the store. To avoid errors when verifying the names and versions of such packages in the store, you may now set the strict-store-pkg-content-check setting to false #​4724.

Patch Changes

• Fix package-manager-strict-version missing in config #​8195.
• If install is performed on a subset of workspace projects, always create an up-to-date lockfile first. So, a partial install can be performed only on a fully

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.