* fix(package-bins): reject reserved manifest bin names
Manifest bin keys "", ".", "..", and scoped forms such as "@scope/.."
passed the bin-name guard because encodeURIComponent leaves them
unchanged. When joined to the global bin directory during global
remove/update/add operations, "." resolves to the bin directory itself
and ".." to its parent, which removeBin then recursively deletes.
Reject empty, ".", and ".." bin names after scope stripping.
Backport of pnpm/pnpm#12289 to v10.
* fix: block untrusted request destination env expansion
Makes environment expansion trust-aware for registry/auth config and
request destinations:
- Stops project and workspace .npmrc files from expanding ${...}
placeholders in registry/proxy request destinations, URL-scoped keys,
and registry credential values.
- Stops repository-controlled pnpm-workspace.yaml from expanding
${...} placeholders in the registry setting.
- Preserves env expansion for trusted user/global/CLI/env config so
existing token and registry setup flows continue to work.
Backport of pnpm/pnpm#12291 (CAND-PNPM-122 / GHSA-3qhv-2rgh-x77r) to v10.
* fix(security): verify npm registry signature before spawning a package-manager binary
The packageManager field (and pnpm self-update) makes pnpm download and
run a specific pnpm version. The staged install's bytes were trusted
based on lockfile integrity alone, which proves nothing when the inputs
are repository-controlled.
pnpm now verifies the npm registry signature of the engine it is about
to spawn, over the installed integrity, against npm's public signing
keys embedded in the pnpm CLI (exactly as corepack does):
- verifyPnpmEngineIdentity() checks pnpm/@pnpm/exe and the materialized
platform binaries of the staged install before it is linked into the
tools directory.
- Fails closed: any verification failure, including an unreachable
registry, refuses the version switch rather than running an unverified
binary. Runs only on a tools-directory cache miss (an actual
download).
- The embedded keys live in a generated file kept in sync with npm's
keys endpoint by scripts/update-npm-signing-keys.mjs; the release
workflow runs the check as a gate so a key rotation cannot silently
break verification.
Backport of pnpm/pnpm#12292 (CAND-PNPM-097) to v10.
* fix: harden package-manager bootstrap metadata
Resolve package-manager bootstrap traffic through trusted user/CLI
registries and trusted network config, defaulting to the public npm
registry instead of project/workspace registry settings:
- getConfig() now computes packageManagerRegistries and
packageManagerNetworkConfig from trusted config sources only (CLI
options, env config, user and global .npmrc) — never the repository's
project/workspace .npmrc or pnpm-workspace.yaml.
- switchCliVersion() applies that bootstrap config when installing and
verifying the wanted pnpm version, so repository .npmrc
proxy/TLS/registry values cannot steer package-manager bootstrap
traffic.
Backport of pnpm/pnpm#12296 to v10. The v11 env-lockfile validation
parts do not apply: v10 bootstraps the wanted version through a staged
child install instead of an env lockfile.
* fix(security): verify Node.js runtime SHASUMS OpenPGP signature
When a repository requests a Node.js runtime (useNodeVersion or an
execution env), pnpm downloads and then executes a Node binary. The
download mirror is repository-configurable via node-mirror:<channel> in
project .npmrc, and the integrity came from SHASUMS256.txt fetched from
that same mirror — a circular check a malicious mirror can satisfy with
a tampered binary and matching hashes.
pnpm now fetches SHASUMS256.txt.sig and verifies its detached OpenPGP
signature against the Node.js release team's public keys, embedded in
the pnpm CLI, before trusting the hashes:
- @pnpm/crypto.shasums-file: new fetchVerifiedNodeShasums /
fetchVerifiedNodeShasumsFile verify the signature via openpgp against
the embedded keys (generated src/nodeReleaseKeys.ts, mirrored from
the canonical nodejs/release-keys list).
- @pnpm/node.fetcher verifies the configurable-mirror SHASUMS for the
release channel; pre-release channels (rc, nightly, ...) are unsigned
by Node and remain unverified.
- scripts/update-node-release-keys.mjs keeps the keys current
(pnpm run check:node-release-keys / update:node-release-keys), and
the release workflow runs the check as a gate.
Backport of pnpm/pnpm#12295 to v10 (without the pacquet Rust port,
which does not exist on this branch).
* test(env): sign the SHASUMS fixture for Node.js download tests
The Node.js download tests exercise the release channel, whose
SHASUMS256.txt is now signature-verified. Sign the fixture with a
generated OpenPGP key and trust it through the new
trustedNodeReleaseKeys test seam (threaded from plugin-commands-env via
@pnpm/node.fetcher to fetchVerifiedNodeShasums), so the tests keep
exercising the verification path instead of bypassing it.
* fix(self-updater): redact registry credentials from engine identity errors
Registry URLs may legally embed basic-auth credentials
(https://user:pass@host/). verifyPnpmEngineIdentity() interpolated the
packument URL and registry URL into PnpmError messages, and the
unreachable-registry path surfaced fetch-layer error messages that embed
the request URL — all of which land in terminal output and CI logs.
Strip URL credentials from every error message and truncate the non-200
response body.
* fix: update vulnerable transitive dependencies
Override shell-quote to >=1.8.4 (GHSA-w7jw-789q-3m8p, critical, pulled
in via concurrently) so the audit workflow passes again. The advisory
was published after the last release/10 audit run; it is unrelated to
the security backports on this branch.
The `pnpm/bundle` step runs `ts-node bundle.ts`, which transitively
loads `esm@3.2.25` (via `publish-packed` → `all-module-paths` → `esm`).
That package monkey-patches Node internals removed in Node 22+. The
release workflow runs on `ubuntu-latest` and was relying on the
runner's default Node; GitHub bumping that default between 10.33.4
and 10.34.0 silently broke the publish phase.
Pin Node 20 — the last release line `esm@3.2.25` still works on — and
drop `continue-on-error` from the Publish step so future failures fail
the workflow instead of hiding behind a green check.
The upstream `https://gitlab.com/opensource-saurik/ldid.git` is no
longer publicly accessible (returns 401 / redirects to sign-in), so
`git clone` prompts for a username and fails non-interactively with
`could not read Username for 'https://gitlab.com'`. This blocks every
v10 release.
`ProcursusTeam/ldid` is a maintained GitHub fork that contains the
exact commit the workflow pins (c2f8abf), and the libplist submodule
already points at github.com, so a one-line URL swap is the full fix.
---
Written by an agent (Claude Code, claude-opus-4-7).
* Revert "docs: update CONTRIBUTING.md for Git LFS (#8647)"
This reverts commit ccf5fbc1b2.
* Revert "chore: use Git LFS for pnpm development (#8509)"
This reverts commit 5fea44486e.
Sometimes new versions of Node.js make pnpm fail. We are spending more time than needed to investigate such issues because we cannot know that a new Node.js version got installed in CI
* chore: set up git-lfs hooks
* ci: checkout lfs files on CI
According to https://github.com/actions/checkout, checkout out LFS files
defaults to false.
* chore: track .tgz files in Git LFS
