[joshavant]

Problem and change

The selected pnpm12 release has an independent native TLS verifier that can accept the compromised eMudhra keys. Use native pnpm12.15.0 for package downloads through its independently fixed Rust TLS verifier. This combined candidate also retains the prepared fixed Node patch selections within the existing supported majors. Update the existing package-manager owner and regenerate its toolchain lock with the released package; the workspace dependency documents remain byte-identical.

Validation and remaining scope

The frozen install passes. The macOS Swift build, signing, and reminder integration gates cannot run on the Linux arm64 worker and remain required. The qualified native pnpm frozen install passes. Independent review is clean through P2; git diff --check passes. Official Linux arm64 pnpm12.15.0 rejects all36 incident trust cases, including explicit old CA inputs, and passes ordinary npm and private-CA controls. Platform-specific and hosted gates remain required.

Native macOS proof and provider-owned action/runner runtimes remain separate obligations.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs real behavior proof before merge.

What this changes

This PR updates Node to 26.12.1 and pnpm to 12.15.0 and regenerates pnpm’s toolchain lock entries.

Example: A developer installs the repository’s pinned package manager.

• Before: The project selects pnpm 12.14.0.
• After: The project selects pnpm 12.15.0 with matching published integrity hashes.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The pin and lockfile changes are coherent and published hashes match, but the central native security claim has no inspectable final-effect proof.
Proof confidence	🧂 unranked krab (1/6)	Real behavior proof is necessary before merge. See Before merge.
Patch quality	🦐 gold shrimp (3/6)	Security review found an item that needs attention.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: Package downloads can trust certificate chains containing compromised CA keys.
Reason: The supplied maintainer-authored classification establishes direction, and this narrowly updates existing tooling without adding a configuration surface.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open: main retains the older toolchain pins, and this focused security update has no definite introduced code defect.

Priority: P1
Reviewed head: f355974a61b9ec767f0127e183d98c3f4239dce9

Before merge

• Add real behavior proof - Authority-chain proof required: the body reports Linux arm64 pnpm 12.15.0 rejecting 36 incident cases and passing npm/private-CA controls, but provides no inspectable trace or artifact. Attach redacted terminal output or logs from the selected native executable showing valid downloads succeed and a registry impersonator using compromised keys is rejected before response or package content is accepted, including explicit old-CA inputs and native macOS verification. Redact IPs, API keys, and non-public endpoints. No application storage migration is introduced: lockfile format, workspace dependencies, and persisted reminder data are unchanged. After adding proof, update the PR body, then request a new review with @clawsweeper re-review. The PR author or someone with repository write access can request it.
• Resolve security concern: Establish native verifier rejection independently of Node - pnpm’s native download client selects its own platform, bundled, or explicit CA roots, so Node’s documented blocked-key fix does not prove that the selected pnpm executable rejects an incident chain before accepting registry or package content.
• Resolve merge risk - Before merge, establish that the selected native pnpm artifacts enforce the compromised-key block across platform, bundled-root, and explicit custom-CA verification paths.

Findings

• [medium] Establish native verifier rejection independently of Node — package.json:20

Tests

• Missing end-to-end proof: Supply inspectable native package-download success and compromised-chain rejection traces, including explicit old-CA inputs and the supported macOS artifact; CI and frozen-install assertions do not establish that boundary.

Agent review details

How this fits together

The Node pin selects the runtime for documentation builds, while the package-manager pin and lockfile select the native pnpm executable used by developer commands and package downloads.

flowchart TD
  A[Repository toolchain pins] --> B[Node docs runtime]
  A --> C[Native pnpm executable]
  B --> D[Documentation build]
  C --> E[TLS verification]
  E --> F[Registry metadata and package downloads]

Loading

Technical review

Best possible solution:

Land the existing centralized pin update once the selected native artifacts’ security behavior is established.

Do we have a high-confidence way to reproduce the issue?

No runtime reproduction was performed; the old pins are verified in main, Node’s official release documents the security fix, and pnpm’s reported incident results lack inspectable output.

Is this the best way to solve the issue?

Updating the existing pins and regenerating only their lock entries is the smallest complete repository change, provided the chosen native pnpm artifacts actually enforce the intended rejection.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against f92275521956.

Merge-risk options

Maintainer options:

1. Verify the selected native artifacts (recommended)
   Attach package-download traces showing valid registry and private-CA controls succeeding and compromised-key chains rejected before package data is accepted, including the supported macOS artifact.

Provenance checked

• Node documentation runtime changes intended behavior with a stated reason (d272180: The original tooling PR centralized a reproducible Node pin; the later update at build(deps): update docs tooling and CodeQL #94 selected 26.10.0.)
• pnpm selection and toolchain lock changes intended behavior with a stated reason (4dc0650: build(deps): update pnpm to 12.14.0 #109 updated the existing package-manager owner to 12.14.0 and regenerated its lock entries; this PR states a security reason for the replacement.)

Testing

Proof path: none.

Security

Needs attention: No introduced exploit is established, but the native TLS authority boundary needs final-effect verification.

Evidence

Security concerns:

• [medium] Establish native verifier rejection independently of Node — package.json:20
  pnpm’s native download client selects its own platform, bundled, or explicit CA roots, so Node’s documented blocked-key fix does not prove that the selected pnpm executable rejects an incident chain before accepting registry or package content.
  Confidence: 0.98

What I checked:

• Exact introduced change: The pinned diff changes only the Node version, packageManager version, and corresponding pnpm toolchain lock entries; the workspace dependency document remains unchanged. (package.json:20, f355974a61b9)
• Current main still needs the update: Main selects Node 26.10.0 and pnpm 12.14.0; neither proposed pin is already implemented there. (.node-version:1, f92275521956)
• Existing ownership and design: History and ci: pin tooling and streamline verified builds #86 establish the existing centralized toolchain pins; build(deps): update docs tooling and CodeQL #94 and build(deps): update pnpm to 12.14.0 #109 explain subsequent updates. This PR preserves that design. (README.md:308, f92275521956)
• Published package integrity: Read-only npm metadata comparisons matched every changed integrity value, including both Darwin executables and the pnpm wrapper; the wrapper’s published Node engine requirement also matches the lockfile. (pnpm-lock.yaml:15, f355974a61b9)
• Authoritative Node security release: The pinned runtime executes repository documentation tooling. The official release notes at https://github.com/nodejs/node/releases/tag/v26.12.1 explicitly include rejection of chains containing blocked public keys. (bc2e01dcf6ac)
• Independent native trust boundary: The patch selects pnpm’s native executable, so its TLS contract directly governs the claimed fix. Tagged source builds separate platform, bundled-root, and custom-CA clients; updating Node does not establish rejection through those clients. Upstream contribution-only policies do not require release-owned edits in remindctl. (pnpm/crates/network/src/client_builder.rs, 91774e72a04d)

Labels

Label changes:

• add P1: This addresses compromised certificate-key trust in developer package-download tooling.
• add merge-risk: 🚨 security-boundary: The selected executable changes the TLS authority used to accept registry responses and package bytes, and its incident rejection behavior remains unverified.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Label justifications:

• P1: This addresses compromised certificate-key trust in developer package-download tooling.
• merge-risk: 🚨 security-boundary: The selected executable changes the TLS authority used to accept registry responses and package bytes, and its incident rejection behavior remains unverified.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Add final-effect proof that valid registry downloads succeed and compromised-key impersonators are rejected through the selected native pnpm trust paths, including macOS.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed October 21, 2026, 6:54 PM ET / 22:54 UTC.