chore(deps): update pnpm to v9.15.0 [security] #371
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
9.4.0+sha512.f549b8a52c9d2b8536762f99c0722205efc5af913e77835dbccc3b0b0b2ca9e7dc8022b78062c17291c48e88749c70ce88eb5a74f1fa8c4bf5e18bb46c8bd83a
->9.15.0
>=8.5.0
->>=9.15.0
Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
pnpm no-script global cache poisoning via overrides /
ignore-scripts
evasionCVE-2024-53866 / GHSA-vm32-9rqf-rh3r
More information
Details
Summary
pnpm seems to mishandle overrides and global cache:
This can make workspace A (even running with
ignore-scripts=true
) posion global cache and execute scripts in workspace BUsers 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 cachePoC
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
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
A/package.json
:pnpm i --ignore-scripts
(the flag is not required, but the point of the demo is to show that it doesn't help)B/package.json
:pnpm i
Result:
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
Severity
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H
References
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
pnpm incorrectly parses tar archives relative to specification
CVE-2023-37478 / GHSA-5r98-f33j-g8h7
More information
Details
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
package/package.json
z/package.json
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 hasreact@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.
Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
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
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.ERR_PNPM_TARBALL_EXTRACT
error while installing a dependency from GitHub having a slash in branch name #7697.use-node-version
setting is used and the system has no Node.js installed #8769..npmrc
files to their correct types. For instance,child-concurrency
should be a number, not a string #5075.manage-package-manager-versions
is set totrue
.pnpm init
should respect the--dir
option #8768.Platinum Sponsors
Gold Sponsors
v9.14.0
Compare Source
v9.13.2
: pnpm 9.13.2Compare Source
Patch Changes
dlx
processes.Platinum Sponsors
Gold Sponsors
Silver Sponsors
v9.13.1
: pnpm 9.13.1Compare Source
Patch Changes
Platinum Sponsors
Gold Sponsors
Silver Sponsors
v9.13.0
: pnpm 9.13Compare Source
Minor Changes
The
self-update
now accepts a version specifier to install a specific version of pnpm. E.g.:or
Patch Changes
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
node_modules
, when typing "n" in the prompt that asks whether to removenode_modules
before installation #8655.manage-package-manager-versions=true
is set and the.tools
directory is corrupt.crypto.hash
, when available, for improved performance #8629.package.json
at the root of the workspace #8667.manage-package-manager-versions
is set totrue
, errors spawning a self-managed version ofpnpm
will now be shown (instead of being silent).v9.12.2
Compare Source
Patch Changes
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.EBUSY
errors caused by creating symlinks in paralleldlx
processes #8604.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 insidepnpm-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 removelodash
from the dependencies, use this configuration inpackage.json
:Patch Changes
pnpm list --json pkg
showed"private": false
for a private package #8519.libc
that differ frompnpm.supportedArchitectures.libc
are not downloaded #7362.ENOENT
errors caused by runningstore prune
in parallel #8586.pnpm bugs
#8596.v9.11.0
Compare Source
Minor Changes
pnpm cache
commands for inspecting the metadata cache #8512.Patch Changes
pnpm deploy
withnode-linker=hoisted
produces an emptynode_modules
directory #6682.pnpm deploy
should work in workspace withshared-workspace-lockfile=false
#8475.v9.10.0
Compare Source
Minor Changes
Support for a new CLI flag,
--exclude-peers
, added to thelist
andwhy
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
atpnpm.auditConfig.ignoreGhsas
for ignoring vulnerabilities by their GHSA code #6838.For instance:
Patch Changes
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 theform
andbutton
packages.card
hasreact-dom
andreact
as regular dependencies andcard
is a dependency ofform
.These are the direct dependencies of our example project:
These are the dependencies of card:
When resolving peers, pnpm will not re-resolve
react-dom
forcard
, even thoughcard
shadowsreact@16
from the root withreact@17
. So, all 3 packages (form
,card
, andbutton
) will usereact-dom@16
, which in turn usesreact@16
.form
will usereact@16
, whilecard
andbutton
will usereact@17
.Before this optimization
react-dom@16
was duplicated for thecard
, so thatcard
andbutton
would use areact-dom@16
instance that usesreact@17
.Before the change:
After the change
Patch Changes
pnpm deploy
should write thenode_modules/.modules.yaml
to thenode_modules
directory within the deploy directory #7731.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 itspackage.json
file, pnpm will update its version in thepackageManager
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 thepackageManager
field. pnpm was installing the version of pnpm specified in thepackageManager
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-runpnpm patch
.v9.7.1
Compare Source
Patch Changes
public-hoist-pattern
andhoist-pattern
via env variables #8339.pnpm setup
no longer creates Batch/Powershell scripts on Linux and macOS #8418.pnpm exec
now supports executionEnv #8356.pnpm
field, add warnings for non-rootpnpm
subfields that aren'texecutionEnv
#8143.patch-commit
in which relative path is rejected #8405.@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 totrue
, pnpm will switch to the version specified in thepackageManager
field ofpackage.json
#8363. This is the same field used by Corepack. Example: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 ofthe package. Failures will be skipped.
If it is a package name and an exact version (e.g.
[email protected]
), pnpm will attempt to apply the patch to that exact version only. Failures willcause pnpm to fail.
If there's only one version of
pkg
installed,pnpm patch pkg
and subsequentpnpm patch-commit $edit_dir
will create an entry namedpkg
inpnpm.patchedDependencies
. And pnpm will attempt to apply this patch to other versions ofpkg
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 apkg
entry inpnpm.patchedDependencies
.If the user chooses not to apply the patch to all,
pnpm patch-commit $edit_dir
would create a[email protected]
entry inpnpm.patchedDependencies
withx.y.z
being the version the user chose to edit.If the user runs
pnpm patch [email protected]
withx.y.z
being the exact version ofpkg
that has been installed,pnpm patch-commit $edit_dir
will alwayscreate a
[email protected]
entry inpnpm.patchedDependencies
.Change the default edit dir location when running
pnpm patch
from a temporary directory tonode_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 runnode-gyp rebuild
if the project has abinding.gyp
file even if the project doesn't have an install script #8293.v9.6.0
Compare Source
Minor Changes
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 becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.