• Create PR with unit tests
• Commit unit tests in branch backport/v10-allowbuilds-deppath

Description

assertRegistryShapedResolution() treats any non-empty non-string resolution.tarball as
registry-shaped, so a corrupted/tampered lockfile can bypass ERR_PNPM_RESOLUTION_SHAPE_MISMATCH.
Downstream code assumes tarball is string-like (e.g. calls startsWith), which can turn
corruption into a runtime TypeError instead of a clear validation error.

Code

lockfile/utils/src/assertRegistryShapedResolution.ts[R38-77]

+function isRegistryShapedResolution (resolution: unknown): boolean {
+  if (resolution == null) return true
+  if (typeof resolution !== 'object') return false
+  const { type, gitHosted, tarball, variants } = resolution as {
+    type?: unknown
+    gitHosted?: unknown
+    tarball?: unknown
+    variants?: unknown
+  }
+  if (type === 'variations') {
+    return Array.isArray(variants) && variants.every(
+      (variant) => isRegistryShapedResolution((variant as { resolution?: unknown })?.resolution)
+    )
+  }
+  if (type != null) return false
+  // Plain tarball / registry resolution. The lockfile is parsed from YAML
+  // without schema validation, so the `gitHosted` flag is not trustworthy on
+  // its own: a tampered entry could set a non-boolean (dodging a strict
+  // `=== true`) or an explicit `false` on a git-host URL (the loader only
+  // backfills the flag when absent). Treat any non-boolean flag as git-hosted
+  // and gate on the URL so the verdict never depends on the flag alone.
+  if (gitHosted != null && (typeof gitHosted !== 'boolean' || gitHosted)) return false
+  // A registry resolution reconstructs its tarball URL from name+version, so
+  // an absent/empty `tarball` is registry-shaped. When a URL with a scheme is
+  // present it must be an http(s) artifact: a `file:` tarball under a
+  // name@semver key is a local artifact that a package-name rule must not
+  // approve.
+  if (typeof tarball === 'string' && tarball !== '') {
+    if (hasUrlScheme(tarball)) {
+      if (!/^https?:\/\//i.test(tarball)) return false
+      if (isGitHostedTarballUrl(tarball)) return false
+    } else if (tarball.startsWith('/') || tarball.startsWith('\\')) {
+      // Protocol-relative and path-absolute forms (`//host`, `/\host`, ...)
+      // can escape the configured registry host when resolved as a URL.
+      return false
+    }
+    // A scheme-less relative path is resolved against the configured
+    // registry, so it cannot point off-registry.
+  }
+  return true

Evidence

The new shape check only inspects tarball when it is a non-empty string, so a non-string tarball
value passes as registry-shaped. pkgSnapshotToResolution() subsequently uses string methods on
resolution.tarball (and passes it to URL-related checks), which will throw if tarball is not
actually a string.

lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
lockfile/utils/src/pkgSnapshotToResolution.ts[28-33]

Agent prompt

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

## Issue description
`isRegistryShapedResolution()` only validates `tarball` when it is a non-empty string. If `tarball` is present but not a string (e.g. number/object due to lockfile corruption/tampering), the function returns `true` and `assertRegistryShapedResolution()` will not throw `ERR_PNPM_RESOLUTION_SHAPE_MISMATCH`. Later code paths treat `tarball` as a string and may throw a `TypeError`, yielding a less actionable failure mode and weakening the new fail-closed invariant.
### Issue Context
This PR introduces offline shape validation to ensure registry-shaped depPaths are backed by registry-shaped resolutions. Since lockfiles are parsed from YAML without schema validation, the shape check should also reject structurally invalid field types (like non-string `tarball`) rather than letting them pass.
### Fix Focus Areas
- lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
### Suggested fix
- In `isRegistryShapedResolution()`, add a guard such as:
- `if (tarball != null && typeof tarball !== 'string') return false`
- (Optional but aligned) consider similar strictness for other inspected fields (`variants`, etc.) to keep the invariant “shape check fails closed on malformed data.”

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

Description

isRegistryShapedResolution() returns true when pkgSnapshot.resolution is null/undefined, so a
registry-style depPath can pass assertRegistryShapedResolution() even when the lockfile entry is
malformed. This bypasses the intended ERR_PNPM_RESOLUTION_SHAPE_MISMATCH protection and can lead
to later crashes when other code assumes resolution is an object.

Code

lockfile/utils/src/assertRegistryShapedResolution.ts[R38-40]

+function isRegistryShapedResolution (resolution: unknown): boolean {
+  if (resolution == null) return true
+  if (typeof resolution !== 'object') return false

Evidence

The new guard explicitly treats resolution == null as registry-shaped, even though
PackageSnapshot.resolution is required by the lockfile types and downstream code assumes it is an
object and reads properties like type/integrity after the assertion runs.

lockfile/utils/src/assertRegistryShapedResolution.ts[28-40]
lockfile/types/src/index.ts[41-50]
lockfile/utils/src/pkgSnapshotToResolution.ts[15-33]
exec/plugin-commands-rebuild/src/implementation/index.ts[399-404]

Agent prompt

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

### Issue description
`assertRegistryShapedResolution()` is intended to enforce that registry-shaped depPaths (`name@semver`) are backed by registry-shaped resolutions. However, `isRegistryShapedResolution()` currently treats `null`/`undefined` `resolution` values as registry-shaped (`return true`), which allows malformed/tampered lockfile entries to bypass the invariant check.

### Issue Context
- The lockfile is parsed from YAML without schema validation, so missing fields are possible.
- Other code paths (e.g. `pkgSnapshotToResolution`) immediately access `resolution.type` / `resolution.integrity`, which will throw if `resolution` is missing.

### Fix Focus Areas
- Make `isRegistryShapedResolution()` return `false` (or throw a targeted `PnpmError`) when `resolution == null` for registry-style depPaths.
- Ensure the `variations` branch also fails closed if any variant has a missing/invalid `resolution`.

- lockfile/utils/src/assertRegistryShapedResolution.ts[38-50]

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

Description

rebuildSelectedPkgs() calls matchesDepPath() for every pkg spec, and matchesDepPath() linearly
scans all lockfile package keys each time, making selection O(M×N). This can significantly slow
rebuild/installs when many packages are passed to rebuild (e.g. replaying lots of previously-ignored
builds) on large lockfiles.

Code

exec/plugin-commands-rebuild/src/implementation/index.ts[R175-178]

+function matchesDepPath (packages: PackageSnapshots, pkgSpec: string): boolean {
+  const normalizedPkgSpec = dp.removePeersSuffix(pkgSpec)
+  return Object.keys(packages).some((depPath) => dp.removePeersSuffix(depPath) === normalizedPkgSpec)
+}

Evidence

The rebuild selector creation calls matchesDepPath(packages, arg) for each arg, and
matchesDepPath() scans all package keys via Object.keys(packages).some(...), so runtime grows
with both the number of args and the number of lockfile entries; runUnignoredDependencyBuilds()
can supply many pkg specs into rebuildSelectedPkgs() when replaying previously ignored builds.

exec/plugin-commands-rebuild/src/implementation/index.ts[121-178]
pkg-manager/core/src/install/index.ts[869-889]

Agent prompt

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

## Issue description
`rebuildSelectedPkgs()` determines whether each CLI arg is a depPath by calling `matchesDepPath(packages, arg)`, which currently scans `Object.keys(packages)` for every arg. This creates O(pkgSpecs × packageCount) behavior and can become a bottleneck on large lockfiles or when many ignored builds are replayed.
### Issue Context
- `matchesDepPath()` is called from `pkgSpecs.map(...)`.
- `matchesDepPath()` currently does `Object.keys(packages).some(...)`, repeatedly re-iterating the full package key list.
### Fix Focus Areas
- Build a `Set` (or `Map`) of normalized depPaths once (e.g. `new Set(Object.keys(packages).map(dp.removePeersSuffix))`) and then make `matchesDepPath()` an O(1) membership check.
- Ensure normalization is consistent with the selector comparison logic (peer suffix stripped, patch hash preserved).
- exec/plugin-commands-rebuild/src/implementation/index.ts[121-178]

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

Description

assertRegistryShapedResolution() treats any non-empty non-string resolution.tarball as
registry-shaped, so a corrupted/tampered lockfile can bypass ERR_PNPM_RESOLUTION_SHAPE_MISMATCH.
Downstream code assumes tarball is string-like (e.g. calls startsWith), which can turn
corruption into a runtime TypeError instead of a clear validation error.

Code

lockfile/utils/src/assertRegistryShapedResolution.ts[R38-77]

+function isRegistryShapedResolution (resolution: unknown): boolean {
+  if (resolution == null) return true
+  if (typeof resolution !== 'object') return false
+  const { type, gitHosted, tarball, variants } = resolution as {
+    type?: unknown
+    gitHosted?: unknown
+    tarball?: unknown
+    variants?: unknown
+  }
+  if (type === 'variations') {
+    return Array.isArray(variants) && variants.every(
+      (variant) => isRegistryShapedResolution((variant as { resolution?: unknown })?.resolution)
+    )
+  }
+  if (type != null) return false
+  // Plain tarball / registry resolution. The lockfile is parsed from YAML
+  // without schema validation, so the `gitHosted` flag is not trustworthy on
+  // its own: a tampered entry could set a non-boolean (dodging a strict
+  // `=== true`) or an explicit `false` on a git-host URL (the loader only
+  // backfills the flag when absent). Treat any non-boolean flag as git-hosted
+  // and gate on the URL so the verdict never depends on the flag alone.
+  if (gitHosted != null && (typeof gitHosted !== 'boolean' || gitHosted)) return false
+  // A registry resolution reconstructs its tarball URL from name+version, so
+  // an absent/empty `tarball` is registry-shaped. When a URL with a scheme is
+  // present it must be an http(s) artifact: a `file:` tarball under a
+  // name@semver key is a local artifact that a package-name rule must not
+  // approve.
+  if (typeof tarball === 'string' && tarball !== '') {
+    if (hasUrlScheme(tarball)) {
+      if (!/^https?:\/\//i.test(tarball)) return false
+      if (isGitHostedTarballUrl(tarball)) return false
+    } else if (tarball.startsWith('/') || tarball.startsWith('\\')) {
+      // Protocol-relative and path-absolute forms (`//host`, `/\host`, ...)
+      // can escape the configured registry host when resolved as a URL.
+      return false
+    }
+    // A scheme-less relative path is resolved against the configured
+    // registry, so it cannot point off-registry.
+  }
+  return true

Evidence

The new shape check only inspects tarball when it is a non-empty string, so a non-string tarball
value passes as registry-shaped. pkgSnapshotToResolution() subsequently uses string methods on
resolution.tarball (and passes it to URL-related checks), which will throw if tarball is not
actually a string.

lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
lockfile/utils/src/pkgSnapshotToResolution.ts[28-33]

Agent prompt

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

## Issue description
`isRegistryShapedResolution()` only validates `tarball` when it is a non-empty string. If `tarball` is present but not a string (e.g. number/object due to lockfile corruption/tampering), the function returns `true` and `assertRegistryShapedResolution()` will not throw `ERR_PNPM_RESOLUTION_SHAPE_MISMATCH`. Later code paths treat `tarball` as a string and may throw a `TypeError`, yielding a less actionable failure mode and weakening the new fail-closed invariant.
### Issue Context
This PR introduces offline shape validation to ensure registry-shaped depPaths are backed by registry-shaped resolutions. Since lockfiles are parsed from YAML without schema validation, the shape check should also reject structurally invalid field types (like non-string `tarball`) rather than letting them pass.
### Fix Focus Areas
- lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
### Suggested fix
- In `isRegistryShapedResolution()`, add a guard such as:
- `if (tarball != null && typeof tarball !== 'string') return false`
- (Optional but aligned) consider similar strictness for other inspected fields (`variants`, etc.) to keep the invariant “shape check fails closed on malformed data.”

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

Description

rebuildSelectedPkgs() calls matchesDepPath() for every pkg spec, and matchesDepPath() linearly
scans all lockfile package keys each time, making selection O(M×N). This can significantly slow
rebuild/installs when many packages are passed to rebuild (e.g. replaying lots of previously-ignored
builds) on large lockfiles.

Code

exec/plugin-commands-rebuild/src/implementation/index.ts[R175-178]

+function matchesDepPath (packages: PackageSnapshots, pkgSpec: string): boolean {
+  const normalizedPkgSpec = dp.removePeersSuffix(pkgSpec)
+  return Object.keys(packages).some((depPath) => dp.removePeersSuffix(depPath) === normalizedPkgSpec)
+}

Evidence

The rebuild selector creation calls matchesDepPath(packages, arg) for each arg, and
matchesDepPath() scans all package keys via Object.keys(packages).some(...), so runtime grows
with both the number of args and the number of lockfile entries; runUnignoredDependencyBuilds()
can supply many pkg specs into rebuildSelectedPkgs() when replaying previously ignored builds.

exec/plugin-commands-rebuild/src/implementation/index.ts[121-178]
pkg-manager/core/src/install/index.ts[869-889]

Agent prompt

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

### Issue description
`rebuildSelectedPkgs()` determines whether each CLI arg is a depPath by calling `matchesDepPath(packages, arg)`, which currently scans `Object.keys(packages)` for every arg. This creates O(pkgSpecs × packageCount) behavior and can become a bottleneck on large lockfiles or when many ignored builds are replayed.

### Issue Context
- `matchesDepPath()` is called from `pkgSpecs.map(...)`.
- `matchesDepPath()` currently does `Object.keys(packages).some(...)`, repeatedly re-iterating the full package key list.

### Fix Focus Areas
- Build a `Set` (or `Map`) of normalized depPaths once (e.g. `new Set(Object.keys(packages).map(dp.removePeersSuffix))`) and then make `matchesDepPath()` an O(1) membership check.
- Ensure normalization is consistent with the selector comparison logic (peer suffix stripped, patch hash preserved).

- exec/plugin-commands-rebuild/src/implementation/index.ts[121-178]

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

Description

assertRegistryShapedResolution() treats any non-empty non-string resolution.tarball as
registry-shaped, so a corrupted/tampered lockfile can bypass ERR_PNPM_RESOLUTION_SHAPE_MISMATCH.
Downstream code assumes tarball is string-like (e.g. calls startsWith), which can turn
corruption into a runtime TypeError instead of a clear validation error.

Code

lockfile/utils/src/assertRegistryShapedResolution.ts[R38-77]

+function isRegistryShapedResolution (resolution: unknown): boolean {
+  if (resolution == null) return true
+  if (typeof resolution !== 'object') return false
+  const { type, gitHosted, tarball, variants } = resolution as {
+    type?: unknown
+    gitHosted?: unknown
+    tarball?: unknown
+    variants?: unknown
+  }
+  if (type === 'variations') {
+    return Array.isArray(variants) && variants.every(
+      (variant) => isRegistryShapedResolution((variant as { resolution?: unknown })?.resolution)
+    )
+  }
+  if (type != null) return false
+  // Plain tarball / registry resolution. The lockfile is parsed from YAML
+  // without schema validation, so the `gitHosted` flag is not trustworthy on
+  // its own: a tampered entry could set a non-boolean (dodging a strict
+  // `=== true`) or an explicit `false` on a git-host URL (the loader only
+  // backfills the flag when absent). Treat any non-boolean flag as git-hosted
+  // and gate on the URL so the verdict never depends on the flag alone.
+  if (gitHosted != null && (typeof gitHosted !== 'boolean' || gitHosted)) return false
+  // A registry resolution reconstructs its tarball URL from name+version, so
+  // an absent/empty `tarball` is registry-shaped. When a URL with a scheme is
+  // present it must be an http(s) artifact: a `file:` tarball under a
+  // name@semver key is a local artifact that a package-name rule must not
+  // approve.
+  if (typeof tarball === 'string' && tarball !== '') {
+    if (hasUrlScheme(tarball)) {
+      if (!/^https?:\/\//i.test(tarball)) return false
+      if (isGitHostedTarballUrl(tarball)) return false
+    } else if (tarball.startsWith('/') || tarball.startsWith('\\')) {
+      // Protocol-relative and path-absolute forms (`//host`, `/\host`, ...)
+      // can escape the configured registry host when resolved as a URL.
+      return false
+    }
+    // A scheme-less relative path is resolved against the configured
+    // registry, so it cannot point off-registry.
+  }
+  return true

Evidence

The new shape check only inspects tarball when it is a non-empty string, so a non-string tarball
value passes as registry-shaped. pkgSnapshotToResolution() subsequently uses string methods on
resolution.tarball (and passes it to URL-related checks), which will throw if tarball is not
actually a string.

lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
lockfile/utils/src/pkgSnapshotToResolution.ts[28-33]

Agent prompt

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

## Issue description
`isRegistryShapedResolution()` only validates `tarball` when it is a non-empty string. If `tarball` is present but not a string (e.g. number/object due to lockfile corruption/tampering), the function returns `true` and `assertRegistryShapedResolution()` will not throw `ERR_PNPM_RESOLUTION_SHAPE_MISMATCH`. Later code paths treat `tarball` as a string and may throw a `TypeError`, yielding a less actionable failure mode and weakening the new fail-closed invariant.
### Issue Context
This PR introduces offline shape validation to ensure registry-shaped depPaths are backed by registry-shaped resolutions. Since lockfiles are parsed from YAML without schema validation, the shape check should also reject structurally invalid field types (like non-string `tarball`) rather than letting them pass.
### Fix Focus Areas
- lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
### Suggested fix
- In `isRegistryShapedResolution()`, add a guard such as:
- `if (tarball != null && typeof tarball !== 'string') return false`
- (Optional but aligned) consider similar strictness for other inspected fields (`variants`, etc.) to keep the invariant “shape check fails closed on malformed data.”

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

Description

assertRegistryShapedResolution() treats any non-empty non-string resolution.tarball as
registry-shaped, so a corrupted/tampered lockfile can bypass ERR_PNPM_RESOLUTION_SHAPE_MISMATCH.
Downstream code assumes tarball is string-like (e.g. calls startsWith), which can turn
corruption into a runtime TypeError instead of a clear validation error.

Code

lockfile/utils/src/assertRegistryShapedResolution.ts[R38-77]

+function isRegistryShapedResolution (resolution: unknown): boolean {
+  if (resolution == null) return true
+  if (typeof resolution !== 'object') return false
+  const { type, gitHosted, tarball, variants } = resolution as {
+    type?: unknown
+    gitHosted?: unknown
+    tarball?: unknown
+    variants?: unknown
+  }
+  if (type === 'variations') {
+    return Array.isArray(variants) && variants.every(
+      (variant) => isRegistryShapedResolution((variant as { resolution?: unknown })?.resolution)
+    )
+  }
+  if (type != null) return false
+  // Plain tarball / registry resolution. The lockfile is parsed from YAML
+  // without schema validation, so the `gitHosted` flag is not trustworthy on
+  // its own: a tampered entry could set a non-boolean (dodging a strict
+  // `=== true`) or an explicit `false` on a git-host URL (the loader only
+  // backfills the flag when absent). Treat any non-boolean flag as git-hosted
+  // and gate on the URL so the verdict never depends on the flag alone.
+  if (gitHosted != null && (typeof gitHosted !== 'boolean' || gitHosted)) return false
+  // A registry resolution reconstructs its tarball URL from name+version, so
+  // an absent/empty `tarball` is registry-shaped. When a URL with a scheme is
+  // present it must be an http(s) artifact: a `file:` tarball under a
+  // name@semver key is a local artifact that a package-name rule must not
+  // approve.
+  if (typeof tarball === 'string' && tarball !== '') {
+    if (hasUrlScheme(tarball)) {
+      if (!/^https?:\/\//i.test(tarball)) return false
+      if (isGitHostedTarballUrl(tarball)) return false
+    } else if (tarball.startsWith('/') || tarball.startsWith('\\')) {
+      // Protocol-relative and path-absolute forms (`//host`, `/\host`, ...)
+      // can escape the configured registry host when resolved as a URL.
+      return false
+    }
+    // A scheme-less relative path is resolved against the configured
+    // registry, so it cannot point off-registry.
+  }
+  return true

Evidence

The new shape check only inspects tarball when it is a non-empty string, so a non-string tarball
value passes as registry-shaped. pkgSnapshotToResolution() subsequently uses string methods on
resolution.tarball (and passes it to URL-related checks), which will throw if tarball is not
actually a string.

lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]
lockfile/utils/src/pkgSnapshotToResolution.ts[28-33]

Agent prompt

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

### Issue description
`isRegistryShapedResolution()` only validates `tarball` when it is a non-empty string. If `tarball` is present but not a string (e.g. number/object due to lockfile corruption/tampering), the function returns `true` and `assertRegistryShapedResolution()` will not throw `ERR_PNPM_RESOLUTION_SHAPE_MISMATCH`. Later code paths treat `tarball` as a string and may throw a `TypeError`, yielding a less actionable failure mode and weakening the new fail-closed invariant.

### Issue Context
This PR introduces offline shape validation to ensure registry-shaped depPaths are backed by registry-shaped resolutions. Since lockfiles are parsed from YAML without schema validation, the shape check should also reject structurally invalid field types (like non-string `tarball`) rather than letting them pass.

### Fix Focus Areas
- lockfile/utils/src/assertRegistryShapedResolution.ts[38-77]

### Suggested fix
- In `isRegistryShapedResolution()`, add a guard such as:
 - `if (tarball != null && typeof tarball !== 'string') return false`
- (Optional but aligned) consider similar strictness for other inspected fields (`variants`, etc.) to keep the invariant “shape check fails closed on malformed data.”

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

• ➕ One place to enforce depPath↔resolution invariants (simpler reasoning)
• ➕ Potentially faster by caching verification results
• ➖ Not available/consistent in v10 (no verifyLockfileResolutions pipeline here)
• ➖ Still needs runtime enforcement near script execution to be robust

• ➕ Eliminates ambiguity entirely; approvals always pin to an artifact identity
• ➕ Simplifies policy logic (no trust inference from depPath shape)
• ➖ Major UX regression for normal registry dependencies
• ➖ Large config churn for existing users relying on package-name allowlists

• ➕ Less code and fewer heuristics
• ➕ Cheaper checks at runtime
• ➖ Unsafe if lockfile is tampered (flag can be forged/typed incorrectly)
• ➖ Would reintroduce the core confusion between name@semver keys and non-registry artifacts