Repository navigation
fix(security): pin patched workerd verifier - #169
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. What this changesPin local workerd tooling to 1.20261021.1, regenerate the dependency graph, and document the security fix. Example: Local Wrangler fetches dv-g3b-emudhra.we-have-a-problem.com using the documented additional trust.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it addresses a concrete local TLS verification vulnerability still present on main, and the reviewed diff introduces no actionable defect. Priority: P2 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherWrangler and the Cloudflare Vitest plugin acquire workerd through the workspace dependency graph; its native TLS verifier decides whether local Worker HTTPS connections proceed. flowchart LR
A[Workspace override] --> B[Frozen dependency graph]
B --> C[Wrangler and Workers tests]
C --> D[Native workerd]
D --> E[TLS certificate verification]
E --> F[HTTPS accepted or rejected]
Technical reviewBest possible solution: Land the verified workerd pin through the existing workspace dependency owner while preserving legitimate trust and keeping managed-fleet remediation explicitly outside its scope. Do we have a high-confidence way to reproduce the issue? Main selects the older native verifier, and the supplied matched Wrangler runs demonstrate certificate acceptance before the fix and rejection afterward; this review independently inspected source without executing the reproduction. Is this the best way to solve the issue? The existing workspace override is the smallest complete repository fix, and supplier source confirms that the selected verifier rejects the compromised keys without broadly removing private-CA trust. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 6eb82bab1edf. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/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. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 26, 2026, 5:28 AM ET / 09:28 UTC. |
What Problem This Solves
The repository's acquired local workerd verifier can accept the compromised emSign keys even while the invoking Node runtime is patched.
User Impact
Local Wrangler and applicable Workers tests use workerd 1.20261021.1, which rejects those keys. Cloudflare's managed production runtime remains supplier-owned; dependency installation alone does not establish deployed-fleet remediation.
Why This Change Was Made
Use the existing pnpm workspace override owner and regenerate its lockfile with the declared package manager. Keep Wrangler, Miniflare, source inputs, installation policy and service lifecycle unchanged. Replace every affected nested workerd graph; preserve legitimate private-CA trust.
Evidence
Candidate
c38799f7231953634dd6f051281ca8a094119a6c, base6eb82bab1edf008f86859879fdaea3f7e022c495; native artifact SHA256e98c9ce9473a19405f80bfa8979d0b7aabae6807ec43093b8d3a660e319bbd83.0/14 accepted; 14/14 underlying CertDistrusted; legitimate public/private HTTPS controls:both pass on baseline and candidate.pnpm lint→ 0;pnpm build:sdk→ 0;pnpm --dir apps/admin build→ 0;pnpm typecheck→ 0;pnpm test→ 0;pnpm --dir apps/api exec wrangler deploy --dry-run --outdir dist-proof→ 0;pnpm --dir apps/demo build→ 0;pnpm docs:build→ 0;pnpm verify:sdk-packages→ 0. Workers-pool compatibility and nested-engine identity:All installed workerd binaries match the official Linux ARM64 artifact; no old engine graph remains in the final lock. Existing real Worker suites are included above..canonical independent P0–P3 review completed scoped-clean, no actionable findings; source/lock review is distinct from all-platform qualification. Current-head hosted checks:not yet observed for this new head; consult this PR Checks tab.patch SHA256 067db51e8d3e6c7625f8454664ebf0608ba89d0f3db591de90ff600253c6625e; chain/fixture identities and results below. Platform and trust-mode limits:Hosted native keyring/runtime matrix remains separate. The generated lock also consolidates better-auth peer graphs from jose6.2.12 to already-direct6.2.13 within declared ranges; full existing auth/Worker tests pass. No direct jose requirement changed..Existing automatic effects: PR: CI matrix, CodeQL, ClawSweeper dispatch, native keyring matrix because lock changes. Main: same checks and Docs GitHub Pages deployment because pnpm-lock.yaml matches its path filter. Production Cloudflare deploy is manual-only. Application release v* and SDK npm release sdk-v* require tag/manual events and are not invoked.
No merge, deployment, release, image/package publication or cloud operation was performed during local qualification.
Reproduction and evidence limits
Both revisions use the actual repository-installed Wrangler and its frozen dependency graph, patched Node 24.22.1, identical isolated Pages fetch fixture, historical extra-CA plus system roots, and matching requests. This exercises the acquired local native verifier, not each authenticated application route. No production test seam or trust bypass was added. Each of the 14 endpoint chains passed independent OpenSSL chain/hostname verification and matched verified incident SPKI identities;14chains cover six TLS issuer keys, not the two additional code-signing keys. Supplier/source comparison separately matches the full eight-key denylist. Generic internal-error envelopes are corroborated by 14 exact underlying
CertDistrustedlog entries.Fixture SHA256
8cf12c8291a4d9e76b2f1e63dd93ea1a533f9fe174dca7078e9992579bc18f16; additional-CA SHA2567ddc10d975d45dcb1906a13d984edf8e5fcf13e6877f5a0dbbfd503c4e841e98. No host trust, production service, Docker daemon or Cloudflare setting was changed. Mac/Windows/native x64, outbound WSS, every provider, production managed-runtime identity and fleet uptake remain unverified by this lane.Matched incident endpoint results
Each row has valid independent chain and exact-hostname verification. Baseline TLS completes; candidate fails with underlying CertDistrusted.
Chain-controls JSON SHA256
337b73f7d54256bbbc0af661e648ac2db90b55e066a273baab6d1a63609d94ab; full candidate server log SHA256b80d5e03027cb48f70b451e4bd5b58a76bd08f6aa8de5abb762e09de66df66a1. Both legitimate controls complete HTTPS under the same additional trust. These are TLS acceptance results, not model/application success at the incident sites.