Repository navigation
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 changesThis PR updates the documentation runtime from Node.js 26.10.0 to 26.12.1 and updates the matching contributor instructions. Example: The documentation workflow selects Node through .node-version.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep open: main still selects the affected Node release, and this PR makes a focused security update through the existing runtime selector; no actionable patch defect was found. Priority: P2 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherGitHub Actions reads the shared Node version file, runs the documentation builder against repository Markdown, and publishes the generated static site through the existing Pages workflow. flowchart LR
A[Node version file] --> B[Documentation CI]
A --> C[Pages workflow]
D[Markdown documentation] --> E[Documentation builder]
B --> E
C --> E
E --> F[Static site artifact]
F --> G[GitHub Pages]
Technical reviewBest possible solution: Land the focused version update through the existing shared selector and publication workflow. Do we have a high-confidence way to reproduce the issue? Main demonstrably selects Node.js 26.10.0, and upstream documents the compromised-key rejection shipped in 26.12.1; no incident TLS handshake was independently reproduced. Is this the best way to solve the issue? Updating the existing shared pin is the smallest complete repository change and keeps CI, Pages, and contributor instructions aligned. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 350240e50578. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
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 21, 2026, 6:28 PM ET / 22:28 UTC. |
What Problem This Solves
Documentation CI and Pages consume an affected Node26 patch from .node-version.
User Impact
Select Node26.12.1 through the existing version file and matching contributor instructions.
Why This Change Was Made
Consume the independently qualified normal release through the existing selection owner, keeping supported majors and publication gates.
Evidence
make docspasses under actual Node26.12.1: documentation tests, four link/anchor tests and the complete static site build succeed. Independent review is clean at the repository-required priority. Actual fixed release binaries reject the incident chains with positive controls.The application Go toolchain already selects its fixed1.27.3 release. A future merge of this version-file change triggers the existing GitHub Pages deployment; deployment is not authorized by this preparation.
Also upgrade Alpine
ca-certificatesandca-certificates-bundleto20261020-r0in both image stages before network or build commands. The Go base already contains the older main package, so plainapk add ca-certificatesretains its vulnerable roots. The normal signed package upgrade and real post-install trigger were tested: all twelve incident chains fail with the resulting CA file, hashed CA directory, their union, andcert.pem; a GitHub control succeeds. Application checks from the preceding head remain applicable because application code and build commands are unchanged. Rebuilt image publication and custom CA overrides remain separate.