Repository navigation
fix(ci): reject compromised CA keys in selected Node runtimes - #34
Conversation
|
Codex review: needs real behavior proof before merge. What this changesThis PR pins development, CI, and publishing to Node.js 24.22.1 and records the operational change. Example: A CI job establishes an HTTPS connection whose certificate chain contains a compromised eMudhra intermediate key.
Review scoresProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Blocked before merge - 3 items remain Keep this PR open: main still selects the affected runtime, and the focused selector update addresses a confirmed upstream security issue without an identified patch defect. Priority: P1 Before merge
FindingsNone. Tests
Agent review detailsHow this fits togetherThe runtime selectors provision Node for local development, application validation, migration smoke tests, and npm publishing; those processes consume source and dependencies and produce validated package artifacts. flowchart TD
A[Development and workflow selectors] --> B[Node 24.22.1]
B --> C[Dependency HTTPS requests]
C --> D[TLS certificate verification]
D --> E[Reject compromised keys]
D --> F[Allow valid chains]
F --> G[Validation and package publication]
Technical reviewBest possible solution: Retain the four exact runtime updates and attach the existing TLS verification output before landing. Do we have a high-confidence way to reproduce the issue? Main explicitly selects Node 24.18.0, while the authoritative Node advisory and 24.22.1 release establish the missing incident-key protection; no target code was executed. Is this the best way to solve the issue? Updating the existing exact selectors is the smallest complete repair within the stated tooling boundary, preserving the Node 24 contract and existing publishing controls. AGENTS.md: found but not applied because it conflicted with ClawSweeper's review contract. Codex review notes: model internal, reasoning medium; reviewed against d83339a30cc1. Merge-risk optionsMaintainer options:
Provenance checked
TestingProof path: none. SecurityNeeds attention: No introduced vulnerability was identified, but the changed TLS trust boundary lacks inspectable final-effect evidence. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
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 21, 2026, 5:32 PM ET / 21:32 UTC. |

Problem and change
Build, CI and release tooling can select Node patches that trust the compromised eMudhra keys. Select Node 24.22.1 at the existing version owners, including cache/provisioning inputs. Exact patch selectors also prevent fallback to an older cached patch.
Compatibility and privacy
The selected tooling now uses fixed patches within its existing Node release lines. Application installations and Actions’ bundled runtimes require separate remediation. No package API or session-data contract changes.
Validation
Workflow YAML and git diff --check pass. Actionlint reports only the unchanged baseline concurrency.queue diagnostic. The selected official Linux arm64 Node releases reject all twelve incident chains in eight TLS modes, including explicit old CA inputs, with ordinary HTTPS controls passing. Existing PR CI covers the application/native suites, which were not rerun locally for these selector changes. Operational changelog updated.