Walkthrough

This PR implements npm registry signature verification for pnpm and pacquet binaries before execution. It adds npm signing key infrastructure, embedded key data, installed-package verification APIs, and integrates verification into pnpm self-update and pacquet delegation flows.

Changes

npm Registry Signature Verification for Package Managers

Sequence Diagram(s)

sequenceDiagram
  participant KeySync as update-npm-signing-keys.mjs
  participant NpmKeys as npm /-/npm/v1/keys
  participant EmbeddedKeys as npmSigningKeys.ts
  participant InstallPnpm as installPnpmToStore/installPnpmToGlobalDir
  participant VerifyEngine as verifyPnpmEngineIdentity
  participant VerifyInstalled as verifyInstalledPackageSignatures
  participant Registry as npm registry

  KeySync->>NpmKeys: fetch advertised signing keys
  KeySync->>EmbeddedKeys: merge and refresh NPM_SIGNING_KEYS
  InstallPnpm->>VerifyEngine: verify engine packages
  VerifyEngine->>VerifyInstalled: verify installed signatures
  VerifyInstalled->>Registry: fetch packuments for pnpm/@pnpm/exe/@pnpm/platform
  Registry-->>VerifyInstalled: dist.integrity and dist.signatures
  VerifyInstalled-->>VerifyEngine: categorized failures or verified: true
  VerifyEngine-->>InstallPnpm: continue or throw error

sequenceDiagram
  participant InstallDeps as installDeps
  participant VerifyPacquet as verifyPacquetIdentity
  participant Collect as collectPacquetPackagesToVerify
  participant VerifyInstalled as verifyInstalledPackageSignatures
  participant Registry as npm registry

  InstallDeps->>VerifyPacquet: verify pacquet before delegation
  VerifyPacquet->>Collect: collect pacquet shim and platform binary
  VerifyPacquet->>VerifyInstalled: verify installed signatures
  VerifyInstalled->>Registry: fetch packuments
  Registry-->>VerifyInstalled: packument data
  VerifyInstalled-->>VerifyPacquet: verification result
  VerifyPacquet-->>InstallDeps: return true/false or throw
  InstallDeps->>InstallDeps: enable/disable pacquet delegation

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• pnpm/pnpm#11734: Modifies pacquet delegation initialization in installing/commands/src/installDeps.ts; this PR gates the same delegation point with identity verification.
• pnpm/pnpm#11781: Changes how command-line flags are forwarded to pacquet in the delegation flow; this PR adds a verification checkpoint before that delegation path.

Poem

🐰 Hopping down the registry trail,
Where signatures vouch: "This is real!"
Pacquet and pnpm both check their mail—
Tampered binaries won't steal the deal. ✨

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

Description

collectEnginePackagesToVerify() silently skips engine components whose lockfile entry lacks
resolution.integrity (including the @pnpm/* platform binary), and for the platform binary it breaks
after the first matching candidate even if that candidate wasn’t verifiable. This can allow a
version switch/self-update to proceed after verifying only a subset of components, despite pnpm
still being able to download/install packages without integrity metadata.

Code

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[R92-123]

+function collectEnginePackagesToVerify (envLockfile: EnvLockfile, registries: Registries): InstalledPackageToVerify[] {
+  const pmDeps = envLockfile.importers['.']?.packageManagerDependencies ?? {}
+  const toVerify: InstalledPackageToVerify[] = []
+
+  for (const name of ['pnpm', '@pnpm/exe']) {
+    const version = pmDeps[name]?.version
+    if (version == null) continue
+    const integrity = registryIntegrity(envLockfile.packages[`${name}@${version}`]?.resolution)
+    if (integrity != null) {
+      toVerify.push({ name, version, registry: pickRegistryForPackage(registries, name), integrity })
+    }
+  }
+
+  // The bytes actually executed are the host's `@pnpm/exe` platform binary,
+  // listed as an optional dependency of `@pnpm/exe`.
+  const exeVersion = pmDeps['@pnpm/exe']?.version
+  if (exeVersion != null) {
+    const optionalDeps = envLockfile.snapshots[`@pnpm/exe@${exeVersion}`]?.optionalDependencies ?? {}
+    const libcFamily = familySync()
+    const candidateNames = [
+      `@pnpm/${exePlatformPkgDirName(process.platform, process.arch, libcFamily)}`,
+      `@pnpm/${exePlatformPkgDirNameNext(process.platform, process.arch, libcFamily)}`,
+    ]
+    for (const platformName of candidateNames) {
+      const platformVersion = optionalDeps[platformName]
+      if (platformVersion == null) continue
+      const integrity = registryIntegrity(envLockfile.packages[`${platformName}@${platformVersion}`]?.resolution)
+      if (integrity != null) {
+        toVerify.push({ name: platformName, version: platformVersion, registry: pickRegistryForPackage(registries, platformName), integrity })
+      }
+      break
+    }

Evidence

The engine verifier only adds packages to the verification set when it can read a non-empty
integrity string, and the platform-binary selection loop breaks even if no verifiable entry was
added. Separately, the fetch/install path explicitly supports downloading without integrity, so
skipping verification due to missing integrity can still result in downloaded bytes being executed.

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[92-123]
fetching/tarball-fetcher/src/index.ts[71-104]
store/index/src/index.ts[79-94]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`collectEnginePackagesToVerify()` currently *skips* entries when `resolution.integrity` is missing, and the platform-binary loop `break`s even when the first matching candidate cannot be verified (e.g., missing integrity). This allows **partial verification** and can skip verification of the **actual executed** platform binary.
### Issue Context
pnpm can still download/install tarballs even when `integrity` is missing, so “missing integrity” is not a safe reason to proceed without verification.
### Fix Focus Areas
- engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[92-127]
### What to change
- Treat missing integrity for any *required* engine component (pnpm, @pnpm/exe, and the resolved platform binary) as **unverifiable** and throw `PNPM_ENGINE_IDENTITY_UNVERIFIABLE` (fail closed).
- In the `candidateNames` loop, only `break` after you have successfully collected a verifiable platform package (i.e., version exists *and* integrity exists). If a candidate name exists in `optionalDependencies` but its integrity is missing, continue to the next candidate name; if none are verifiable, fail closed with a clear error.
- Consider returning a structured result from `collectEnginePackagesToVerify()` (e.g., `{toVerify, missing: [...]}`) so the caller can emit a precise error indicating which component(s) lacked integrity metadata.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

installPnpmToStore() now performs a packument fetch via verifyPnpmEngineIdentity(opts) on cache
misses, but the pnpm with command calls installPnpmToStore() without forwarding
configByUri/proxy/TLS-related fetch options, so signature verification can fail in
authenticated/proxied environments even if normal installs would work.

Code

engine/pm/commands/src/self-updater/installPnpm.ts[R107-110]

+  // Reached only on a store cache miss (a genuine download), so verifying the
+  // pnpm engine's registry signature here does not slow down repeated commands.
+  await verifyPnpmEngineIdentity(opts.envLockfile, pnpmVersion, opts)
+

Evidence

installPnpmToStore() now triggers network verification using the passed opts, while pnpm with
passes a reduced set of options that omits configByUri and other network settings needed for
packument fetch/auth.

engine/pm/commands/src/self-updater/installPnpm.ts[91-110]
engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[67-71]
engine/pm/commands/src/with/with.ts[64-88]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`installPnpmToStore()` now calls `verifyPnpmEngineIdentity(opts)` which uses `createFetchFromRegistry(opts)` and `createGetAuthHeaderByURI(opts.configByUri ?? {})` to fetch packuments and authenticate. The `pnpm with` command currently passes only a minimal option object into `installPnpmToStore()`, dropping `configByUri` and proxy/TLS settings, which can break verification behind proxies or when registries require auth.
### Issue Context
Unlike `switchCliVersion()` (which explicitly forwards proxy/TLS options), `with.ts` constructs a narrow options object when calling `installPnpmToStore()`. After this PR, that call path performs additional network requests outside the store controller, so it must receive the same network/auth settings.
### Fix Focus Areas
- engine/pm/commands/src/with/with.ts[64-88]
- engine/pm/commands/src/self-updater/installPnpm.ts[99-125]
- engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[67-71]
### Suggested fix
Update the `installPnpmToStore()` call in `engine/pm/commands/src/with/with.ts` to forward relevant network/auth options (at minimum `configByUri`, and proxy/TLS dispatcher options like `ca/cert/key/httpProxy/httpsProxy/noProxy/strictSsl/localAddress/maxSockets`, plus `timeout` if `fetchTimeout` is available). A simple approach is to spread `opts` into the call and then override `envLockfile/storeController/storeDir/...` fields last, and map `timeout: opts.fetchTimeout` if needed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new pnpm-engine identity verification uses opts.retry for packument fetches, but the
version-switch entrypoints only forward timeout (and proxy/TLS fields) and never construct/pass a
retry policy from fetchRetries/fetchRetry*. Because verification fails closed, transient
registry hiccups that pnpm would normally retry can now abort packageManager version switching /
pnpm with unnecessarily.

Code

pnpm/src/switchCliVersion.ts[R92-105]

+      // Network settings so the engine identity check can reach the canonical
+      // npm registry through the user's proxy / TLS configuration.
+      ca: config.ca,
+      cert: config.cert,
+      key: config.key,
+      httpProxy: config.httpProxy,
+      httpsProxy: config.httpsProxy,
+      noProxy: config.noProxy,
+      strictSsl: config.strictSsl,
+      localAddress: config.localAddress,
+      maxSockets: config.maxSockets,
+      configByUri: config.configByUri,
+      timeout: config.fetchTimeout,
   }))

Evidence

switchCliVersion and pnpm with pass timeout but no retry into installPnpmToStore, while
fetchPackument only applies retries via retry: opts.retry. pnpm’s config model supports
fetchRetries/fetchRetry*, and the store controller demonstrates the intended translation into a
retry object—this translation is missing specifically in these new verification call paths.

pnpm/src/switchCliVersion.ts[83-105]
engine/pm/commands/src/with/with.ts[80-100]
deps/security/signatures/src/verifySignatures.ts[211-226]
config/reader/src/Config.ts[99-105]
store/connection-manager/src/createNewStoreController.ts[100-109]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The engine identity signature verification fetch path (`verifyInstalledPackageSignatures` → `fetchPackument`) only retries when `VerifySignaturesOptions.retry` is provided. The version-switch entrypoints (`switchCliVersion`, `pnpm with`) currently pass `timeout` and proxy/TLS settings but omit `retry`, so these verification requests don’t honor pnpm’s configured retry policy (`fetchRetries`, `fetchRetryFactor`, `fetchRetryMintimeout`, `fetchRetryMaxtimeout`). Since verification fails closed, this can cause avoidable version-switch failures on transient registry/network errors.
### Issue Context
pnpm already has a standard mapping from `fetchRetry*` config to the network client `retry` object (see store controller creation). The signature verification calls should use the same mapping.
### Fix Focus Areas
- pnpm/src/switchCliVersion.ts[83-105]
- engine/pm/commands/src/with/with.ts[80-100]
### Proposed fix
1. In both call sites, add a `retry` field when calling `installPnpmToStore`, e.g.:

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

findSignatureFailure() returns category: 'invalid' for any signature verification issue
(including “unknown key” / “expired key”), contradicting the documented semantics where invalid is
specifically about a signature not validating over installed bytes (tamper signal).

Code

deps/security/signatures/src/verifySignatures.ts[R499-505]

+  // The message is built from the installed integrity, so a signature only
+  // validates when the installed bytes match what the registry signed.
+  const issue = verifyPackageSignatures(
+    { ...pkg, integrity: pkg.integrity, publishedAt: packument.time?.[pkg.version], signatures },
+    trustedKeys
+  )
+  return issue == null ? undefined : { reason: issue.reason ?? 'invalid registry signature', category: 'invalid' }

Evidence

The type doc defines invalid narrowly, but the implementation always returns invalid for any
non-success outcome from verifyPackageSignatures().

deps/security/signatures/src/verifySignatures.ts[406-415]
deps/security/signatures/src/verifySignatures.ts[469-506]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SignatureFailureCategory` documentation distinguishes `invalid` (signature present but does not validate over installed bytes) from `absent` (no trusted signature / not published) and `unreachable`. However, `findSignatureFailure()` currently maps *any* `verifyPackageSignatures()` issue to `category: 'invalid'`, even when the reason is “no corresponding public key can be found” or “key expired”.
### Issue Context
This impacts downstream error classification/messaging (and any branching logic based on `category`), making untrusted-key cases look like byte-tampering.
### Fix Focus Areas
- deps/security/signatures/src/verifySignatures.ts[406-416]
- deps/security/signatures/src/verifySignatures.ts[469-506]
### Suggested fix
Derive `category` based on the specific failure reason:
- Keep `invalid` only for actual cryptographic verification failures (e.g. reason contains `invalid registry signature`).
- Treat “no corresponding public key” and “public key has expired” as `absent` (or introduce a new explicit category like `untrusted` if you want to preserve more detail).
Add/adjust unit tests in `deps/security/signatures/test/verifySignatures.ts` to assert the expected categories for unknown-key/expired-key scenarios.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

verifyPacquetIdentity() returns false (fallback to pnpm engine) whenever
collectPacquetPackagesToVerify() returns undefined, but that undefined currently covers many “cannot
verify / metadata missing” cases (e.g. env lockfile unreadable, missing integrity), not just “no
platform binary”. This contradicts the documented “fail closed unless pacquet has no binary”
behavior and emits a misleading warning that can hide real verification/unverifiable states.

Code

installing/commands/src/verifyPacquetIdentity.ts[R51-55]

+  const toVerify = await collectPacquetPackagesToVerify(packageName, opts.rootDir, opts.registries)
+  if (toVerify == null) {
+    // pacquet has no installed binary for this platform — use pnpm's own engine.
+    return skip(opts.lockfileDir)
+  }

Evidence

verifyPacquetIdentity() converts toVerify == null into a platform-unavailable skip, but
collectPacquetPackagesToVerify() returns undefined for many non-platform reasons (env lockfile
missing/unreadable, shim/integrity missing). readEnvLockfile() can return null for missing/invalid
lockfile content, meaning these cases are reachable and will be mislabeled as “no pacquet binary”.

installing/commands/src/verifyPacquetIdentity.ts[46-56]
installing/commands/src/verifyPacquetIdentity.ts[80-107]
installing/commands/src/verifyPacquetIdentity.ts[114-119]
lockfile/fs/src/envLockfile.ts[27-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`verifyPacquetIdentity()` treats any `undefined` result from `collectPacquetPackagesToVerify()` as “no pacquet binary installed” and returns `false`, which makes `installDeps()` silently fall back to pnpm’s JS engine. However, `collectPacquetPackagesToVerify()` returns `undefined` for multiple other reasons (missing/unreadable env lockfile, missing integrity metadata, etc.), which are *verification-impossible* states and should not be labeled as “platform binary unavailable”.
## Issue Context
The function’s docstring explicitly states it should **fail closed** when signature verification cannot be performed, with the **only** graceful fallback being “pacquet has no binary for this platform”. The current implementation collapses many cases into the fallback path and logs an inaccurate warning.
## Fix Focus Areas
- installing/commands/src/verifyPacquetIdentity.ts[46-107]
- lockfile/fs/src/envLockfile.ts[27-56]
### Suggested implementation approach
1. Change `collectPacquetPackagesToVerify()` to return a richer result, e.g.:
- `{ kind: 'unsupported_platform' }` (only when platform optional dep is missing)
- `{ kind: 'unverifiable', reason: '...' }` (missing env lockfile, missing shim entry, missing integrity, etc.)
- `{ kind: 'verify', packages: InstalledPackageToVerify[] }`
2. In `verifyPacquetIdentity()`:
- Return `false` only for `unsupported_platform`.
- Throw `PnpmError('PACQUET_IDENTITY_UNVERIFIABLE', ...)` for `unverifiable` cases (so the “cannot be checked” path is loud as intended).
3. Update the warning message in `skip()` to match the actual fallback condition (platform unsupported), or remove it if you switch to throwing in all other cases.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The JSDoc for verifyPnpmEngineIdentity() states that if the registry is unreachable it “warns and
returns”, but the implementation throws and refuses to run the downloaded pnpm in all
unreachable/offline cases.

Code

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[R45-49]

+ * Throws when verification detects tampering (an invalid signature) or that a
+ * package/version is absent from the registry. When the registry simply cannot
+ * be reached (offline), it warns and returns: that is not evidence of tampering.
+ * This runs only when the engine is actually being installed (a store cache
+ * miss), so it does not add a network round trip to every command.

Evidence

The comment explicitly says “warns and returns” for offline, but the function throws on verification
network errors and also throws when failures are present.

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[45-49]
engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[69-89]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`verifyPnpmEngineIdentity()` documentation claims offline/unreachable registry scenarios “warn and return”, but the implementation throws a `PnpmError` and fails closed.
### Issue Context
This is an API-contract/documentation mismatch that can mislead future maintainers and callers.
### Fix Focus Areas
- engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[45-89]
### Suggested fix
Update the JSDoc to reflect the actual behavior (fail closed / throw on unreachable registry), or change the implementation if the intended behavior truly is to warn+return (which would conflict with the PR description).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

verifyPnpmEngineIdentity()/verifyPacquetIdentity() currently treats all verification
failures—including purely unreachable (registry/packument fetch) scenarios—as an identity
mismatch, emitting messaging that the installed bytes “do not match a published, signed release”
even when verification could not actually be performed. This misclassifies
offline/proxy/registry-outage cases and misleads triage by implying a confirmed mismatch rather than
an unverifiable result.

Code

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[R83-89]

+  const onlyUnreachable = result.failures.every((f) => f.category === 'unreachable')
+  throw new PnpmError(
+    onlyUnreachable ? 'PNPM_ENGINE_IDENTITY_UNVERIFIABLE' : 'PNPM_ENGINE_IDENTITY_MISMATCH',
+    `Refusing to run pnpm@${pnpmVersion}: its npm registry signature could not be verified ` +
+    `(${describe(result.failures)}). The bytes selected by this project's lockfile/registry do not match a published, signed pnpm release.`,
+    { hint: 'This can indicate a tampered lockfile or a malicious/unreachable registry. Set `pmOnFail` to `ignore` to skip the version switch if this is unexpected.' }
+  )

Evidence

The code path explicitly computes/encounters an “only unreachable” condition (e.g.,
onlyUnreachable) while still appending mismatch wording, indicating the message is not conditioned
on failure categories. At the same time, verifyInstalledPackageSignatures() maps network/packument
fetch errors (e.g., getPackument() failures) into result.failures entries with `category:
'unreachable'` rather than throwing, meaning unreachable-only results occur in real
offline/registry-unavailable situations; yet verifyPacquetIdentity() (and the pnpm engine identity
verifier) does not branch on these categories and always throws a mismatch-style error/message.

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[45-49]
engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[83-89]
deps/security/signatures/src/verifySignatures.ts[444-456]
installing/commands/src/verifyPacquetIdentity.ts[57-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The identity verification wrappers (`verifyPnpmEngineIdentity()` and `verifyPacquetIdentity()`) currently emit “mismatch” errors and wording (e.g., asserting the installed bytes do not match a published, signed release) even when all verification failures are categorized as `unreachable` due to registry/packument fetch problems. This is misleading because in unreachable-only scenarios the verification could not be completed, so the error should be “unverifiable” (or at minimum avoid asserting a byte mismatch).
## Issue Context
`verifyInstalledPackageSignatures()` reports network/packument fetch problems as failures in `result.failures` with `category: 'unreachable'` (e.g., when `getPackument()` throws), not as thrown exceptions; therefore unreachable-only outcomes are expected in offline/proxy-failure/registry-outage situations. Although the pnpm engine verifier already computes an `onlyUnreachable` condition, it still appends mismatch language, and `verifyPacquetIdentity()` treats any `result.verified === false` as a mismatch without inspecting failure categories.
## Fix Focus Areas
- engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[45-49]
- engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts[83-89]
- installing/commands/src/verifyPacquetIdentity.ts[57-76]
- deps/security/signatures/src/verifySignatures.ts[444-457]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• Adds verifyInstalledPackageSignatures() to @pnpm/deps.security.signatures, verifying
  name@version:integrity against dist.signatures using npm's ECDSA-P256 public keys embedded in
  the CLI (corepack-style), so a project-controlled registry cannot supply its own keypair.
• Blocks pacquet engine execution (verifyPacquetIdentity) unless the installed pacquet shim and
  host platform binary carry a valid npm registry signature; fails closed on tamper or unreachable
  registry.
• Blocks pnpm version-switch / self-update (verifyPnpmEngineIdentity) unless pnpm, @pnpm/exe,
  and the host platform binary are registry-signed; check runs only on a store cache miss to avoid
  per-command network cost.
• Embeds npm's current ECDSA signing keys in a generated npmSigningKeys.ts; a create-release-pr
  CI gate and check:npm-signing-keys script fail the release if the embedded keys drift from npm's
  live endpoint.

The following are alternative approaches to this PR:

Recommendation: The embedded-keys approach (corepack-style) is the right choice here. The main alternative — fetching signing keys from the registry at verification time — was the approach in an earlier commit but was correctly replaced: it allows a project-controlled registry to supply its own keypair, defeating the trust model entirely. A third option (Sigstore/TUF-based verification) would be more robust against key compromise but requires significant infrastructure and is not yet standard for npm packages. The current approach is the pragmatic, proven solution.

verifySignatures.ts Add verifyInstalledPackageSignatures() and getNpmSigningKeys() exports +127/-0

Add verifyInstalledPackageSignatures() and getNpmSigningKeys() exports

• Adds 'getNpmSigningKeys()' returning the embedded npm keys, and 'verifyInstalledPackageSignatures()' which verifies installed-on-disk integrity against registry 'dist.signatures' using caller-supplied trusted keys. Failure categories ('invalid', 'absent', 'unreachable') allow callers to distinguish tamper from transient failures.

deps/security/signatures/src/verifySignatures.ts

---

index.ts Export verifyPnpmEngineIdentity from engine/pm/commands +1/-0

Export verifyPnpmEngineIdentity from engine/pm/commands

• Exports the new 'verifyPnpmEngineIdentity' function and its options type from the package's public API.

engine/pm/commands/src/index.ts

---

installPnpm.ts Call verifyPnpmEngineIdentity on store cache miss before installing pnpm +14/-1

Call verifyPnpmEngineIdentity on store cache miss before installing pnpm

• Invokes 'verifyPnpmEngineIdentity' in both 'installPnpmToStore' and 'installPnpmToGlobalDir' only when an actual download occurs (cache miss), so signature verification adds no network cost to repeated commands. Adds 'trustedKeys' as a test seam on 'InstallPnpmOptions'.

engine/pm/commands/src/self-updater/installPnpm.ts

---

verifyPnpmEngineIdentity.ts New module: verify pnpm/exe registry signatures before version switch +136/-0

New module: verify pnpm/exe registry signatures before version switch

• Implements 'verifyPnpmEngineIdentity()' which collects 'pnpm', '@pnpm/exe', and the host platform binary from the env lockfile and verifies their installed integrity against npm's embedded signing keys. Throws 'PNPM_ENGINE_IDENTITY_MISMATCH' on tamper and 'PNPM_ENGINE_IDENTITY_UNVERIFIABLE' when the registry is unreachable (fails closed).

engine/pm/commands/src/self-updater/verifyPnpmEngineIdentity.ts

---

installDeps.ts Gate pacquet engine delegation on verifyPacquetIdentity result +17/-1

Gate pacquet engine delegation on verifyPacquetIdentity result

• Wraps the pacquet config-dependency name resolution with a call to 'verifyPacquetIdentity'; only sets 'pacquetConfigDepName' (and thus delegates to pacquet) if verification passes. Adds inline comment explaining the trust model.

installing/commands/src/installDeps.ts

---

verifyPacquetIdentity.ts New module: verify pacquet shim and platform binary before spawning +120/-0

New module: verify pacquet shim and platform binary before spawning

• Implements 'verifyPacquetIdentity()' which reads the env lockfile, collects the pacquet shim and host '@pacquet/<platform>-<arch>' binary, and verifies their installed integrity against npm's embedded keys. Returns 'false' (graceful fallback) when pacquet has no binary for the current platform; throws 'PACQUET_IDENTITY_MISMATCH' or 'PACQUET_IDENTITY_UNVERIFIABLE' otherwise.

installing/commands/src/verifyPacquetIdentity.ts

---

switchCliVersion.ts Pass network/TLS config to installPnpm so engine identity check can reach the registry +13/-0

Pass network/TLS config to installPnpm so engine identity check can reach the registry

• Forwards 'ca', 'cert', 'key', proxy settings, 'strictSsl', 'localAddress', 'maxSockets', 'configByUri', and 'fetchTimeout' from the user's config into 'installPnpm' options, enabling the new engine identity check to honour the user's proxy and TLS configuration.

pnpm/src/switchCliVersion.ts

---

verifySignatures.ts Add tests for verifyInstalledPackageSignatures and getNpmSigningKeys +90/-1

Add tests for verifyInstalledPackageSignatures and getNpmSigningKeys

• Adds 5 tests for 'verifyInstalledPackageSignatures' covering valid signature, tampered bytes, untrusted key, absent signature, and unpublished package. Adds 1 test for 'getNpmSigningKeys' confirming the embedded keys are present.

deps/security/signatures/test/verifySignatures.ts

---

selfUpdate.test.ts Pass empty trustedKeys to skip signature check in selfUpdate fixture tests +3/-0

Pass empty trustedKeys to skip signature check in selfUpdate fixture tests

• Adds 'trustedKeys: []' to the fixture options so existing selfUpdate tests bypass the new engine identity check (fixture binaries are not signed with npm's real keys).

engine/pm/commands/test/self-updater/selfUpdate.test.ts

---

verifyPnpmEngineIdentity.test.ts New test suite for verifyPnpmEngineIdentity (6 cases) +123/-0

New test suite for verifyPnpmEngineIdentity (6 cases)

• Tests valid signature, tampered bytes, untrusted key, absent version, unreachable registry (fails closed), and empty trusted-keys skip. Uses mock packuments with in-process ECDSA key generation.

engine/pm/commands/test/self-updater/verifyPnpmEngineIdentity.test.ts

---

pacquet-install-engine-identity.md Add changeset for security fix across 4 packages +15/-0

Add changeset for security fix across 4 packages

• Documents the security fix as a minor release for '@pnpm/deps.security.signatures' and patch releases for '@pnpm/installing.commands', '@pnpm/engine.pm.commands', and 'pnpm'.

.changeset/pacquet-install-engine-identity.md

---

create-release-pr.yml Add CI gate to fail release if embedded npm signing keys are stale +7/-0

Add CI gate to fail release if embedded npm signing keys are stale

• Adds a step to the release PR workflow that runs 'update-npm-signing-keys.mjs' in check mode, blocking the release if npm has rotated keys that are not yet embedded in the CLI.

.github/workflows/create-release-pr.yml

---

update-npm-signing-keys.mjs Add script to sync embedded npm signing keys with npm's live endpoint +105/-0

Add script to sync embedded npm signing keys with npm's live endpoint

• New Node.js script that fetches npm's current signing keys and either checks (CI mode) or rewrites the embedded 'npmSigningKeys.ts' file. Preserves retired keys so packages published before a rotation still verify.

deps/security/signatures/scripts/update-npm-signing-keys.mjs

---

npmSigningKeys.ts Add generated file embedding npm's ECDSA-P256 public signing keys +29/-0

Add generated file embedding npm's ECDSA-P256 public signing keys

• Generated TypeScript constant 'NPM_SIGNING_KEYS' containing npm's two current ECDSA-P256 public keys, used as the trust root for verifying package-manager binaries without a runtime network fetch.

deps/security/signatures/src/npmSigningKeys.ts

---

package.json Add @pnpm/deps.security.signatures and auth-header dependencies +3/-0

Add @pnpm/deps.security.signatures and auth-header dependencies

• Adds '@pnpm/deps.security.signatures', '@pnpm/config.pick-registry-for-package', and '@pnpm/network.auth-header' as workspace dependencies to support the new engine identity verification.

engine/pm/commands/package.json

---

tsconfig.json Add TypeScript project references for new security dependencies +9/-0

Add TypeScript project references for new security dependencies

• Adds project references for '@pnpm/config.pick-registry-for-package', '@pnpm/deps.security.signatures', and '@pnpm/network.auth-header'.

engine/pm/commands/tsconfig.json

---

package.json Add security, lockfile, and network dependencies for pacquet identity check +4/-0

Add security, lockfile, and network dependencies for pacquet identity check

• Adds '@pnpm/deps.security.signatures', '@pnpm/lockfile.fs', '@pnpm/network.auth-header', and '@pnpm/network.fetch' as workspace dependencies.

installing/commands/package.json

---

tsconfig.json Add TypeScript project references for security and network packages +12/-0

Add TypeScript project references for security and network packages

• Adds project references for '@pnpm/deps.security.signatures', '@pnpm/lockfile.fs', '@pnpm/network.auth-header', and '@pnpm/network.fetch'.

installing/commands/tsconfig.json

---

package.json Add check:npm-signing-keys and update:npm-signing-keys root scripts +2/-0

Add check:npm-signing-keys and update:npm-signing-keys root scripts

• Exposes two convenience scripts at the monorepo root: 'check:npm-signing-keys' (CI check mode) and 'update:npm-signing-keys' (rewrite mode) wrapping the key-sync script.

package.json

---

pnpm-lock.yaml Update lockfile with new workspace dependency links +21/-0

Update lockfile with new workspace dependency links

• Records the new workspace dependency links for '@pnpm/deps.security.signatures', '@pnpm/config.pick-registry-for-package', '@pnpm/network.auth-header', '@pnpm/network.fetch', and '@pnpm/lockfile.fs' in both 'engine/pm/commands' and 'installing/commands' importers.

pnpm-lock.yaml

---