Repository navigation
fix(ci): pin patched Node 22 and 24 checks - #71
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 pins the existing Node 22 and 24 CI lanes to 22.23.4 and 24.22.1 and records the change in the changelog. Example: A CI runner has Node 22.18.0 cached when setting up the Node 22 lane.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open for landing: the focused CI runtime fix is absent from main, supplied TLS evidence supports its stated scope, and review found no introduced defect. Priority: P2 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherGitHub Actions selects Node through setup-node, then installs dependencies and runs package validation; this change controls that tooling runtime. flowchart TD
A[Pull request or main push] --> B[Node and operating system matrix]
B --> C[Setup exact Node runtime]
C --> D[Install frozen dependencies]
D --> E[Run package checks]
E --> F[Report CI results]
Technical reviewBest possible solution: Land the exact CI runtime pins through the existing setup-node owner while preserving Node 25 compatibility coverage. Do we have a high-confidence way to reproduce the issue? Main's major-only selectors reach setup-node's cache lookup with check-latest disabled, establishing how an older cached patch can be reused; this review did not execute a before-fix runtime. Is this the best way to solve the issue? Exact patch selection is the smallest complete fix at the existing acquisition owner and preserves package engines, platform coverage, action permissions, and the documented Node 25 contract. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against c21eaefa0ecd. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes: No label 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 HistoryReviewed October 23, 2026, 5:51 PM ET / 21:51 UTC (Revision 3). |
|
@clawsweeper re-review The body now includes exact-artifact native Node22/24 TLS diagnostics: 56 typed incident-chain rejections, trusted public/private controls, issuer/hostname negatives, and the retained initial public-HTTP403 harness result. Native-platform package CI passed; Node25 and other-platform TLS modes remain explicit gaps. |
|
🦞👀 Re-review progress:
|
What Problem This Solves
CI can reuse an older cached patch when Node 22 or 24 is selected only by major version, leaving those checks outside the patched certificate-rejection runtime.
User Impact
CI now requests Node22.23.4 and24.22.1 on its existing Linux, macOS and Windows lanes. The Node25 compatibility lane and package runtime range remain unchanged. Node25 is a separate unresolved upstream hold; this change does not claim total CI-runtime remediation.
Why This Change Was Made
Pin the two supported patched release lines at the existing workflow acquisition owner. The release workflow already selects24.22.1.
Evidence
pnpm run checkon isolated Linux ARM64 with each exact Node version: format, build, typecheck, lint,58 router tests, tarball/import check pass on both.git diff --checkpasses.Inspectable retained TLS evidence
The exact Linux ARM64 Node22.23.4 and24.22.1 executables each rejected all14 incident endpoints in built-in and explicit-old-CA modes (56 typed CERT_REVOKED results). Proper private-CA HTTPS succeeds; the fixture observed only its trusted request. Unknown issuer and wrong-hostname controls reject. Both versions accept a legitimate public HTTPS peer. The first Node22 harness returned a nonzero result because GitHub API returned HTTP403 after successful TLS instead of its expected HTTP200; the raw result is retained. A separately named public resource returns200 with the same exact Node22 ELF; incident probes were not repeated. Native macOS/Windows package CI now passes on this final head, but this Linux TLS proof does not establish their verifier modes. Node25 remains explicitly unresolved.
{ "scope": "Actual exact official LinuxARM64 runtimes selected by source proof; native other-platform package CI is separate. No installed fleet claim.", "archiveSHA256": "b2e82ec0ce078c24307afeb45743da9c42e73d008def25e2349722d0c65e447f", "runtimes": [ { "version": "v22.23.4", "platform": "linux", "arch": "arm64", "executableSHA256": "7e48183361053f039294fbbc3ba586722fe756bf296d6cb8195356d10819cd16", "incidentTypedCERT_REVOKED": 28, "modes": [ "builtin", "explicit-old" ], "representative": [ { "host": "dv-g3b-emudhra.we-have-a-problem.com", "mode": "builtin", "acceptedTLS": false, "errorCode": "CERT_REVOKED" }, { "host": "dv-g3b-emudhra.we-have-a-problem.com", "mode": "explicit-old", "acceptedTLS": false, "errorCode": "CERT_REVOKED" } ], "controls": [ { "label": "public", "explicitCA": false, "acceptedTLS": true, "status": 403 }, { "label": "private-trusted", "explicitCA": true, "acceptedTLS": true, "status": 200 }, { "label": "private-untrusted", "explicitCA": false, "acceptedTLS": false, "errorCode": "UNABLE_TO_VERIFY_LEAF_SIGNATURE" }, { "label": "private-wrong-hostname", "explicitCA": true, "acceptedTLS": false, "errorCode": "ERR_TLS_CERT_ALTNAME_INVALID" } ], "ownedPrivateRequests": [ "/trusted" ], "additionalPublicControl": { "url": "https://raw.githubusercontent.com/openclaw/ocm/v0.3.5/Cargo.toml", "acceptedTLS": true, "status": 200 } }, { "version": "v24.22.1", "platform": "linux", "arch": "arm64", "executableSHA256": "c8c5721679d8d1a09e9987e345d5f9a64899bb85f7a384783ba8a93e6e62348a", "incidentTypedCERT_REVOKED": 28, "modes": [ "builtin", "explicit-old" ], "representative": [ { "host": "dv-g3b-emudhra.we-have-a-problem.com", "mode": "builtin", "acceptedTLS": false, "errorCode": "CERT_REVOKED" }, { "host": "dv-g3b-emudhra.we-have-a-problem.com", "mode": "explicit-old", "acceptedTLS": false, "errorCode": "CERT_REVOKED" } ], "controls": [ { "label": "public", "explicitCA": false, "acceptedTLS": true, "status": 200 }, { "label": "private-trusted", "explicitCA": true, "acceptedTLS": true, "status": 200 }, { "label": "private-untrusted", "explicitCA": false, "acceptedTLS": false, "errorCode": "UNABLE_TO_VERIFY_LEAF_SIGNATURE" }, { "label": "private-wrong-hostname", "explicitCA": true, "acceptedTLS": false, "errorCode": "ERR_TLS_CERT_ALTNAME_INVALID" } ], "ownedPrivateRequests": [ "/trusted" ] } ] }