fix(ci): repair patch-validator cache and embedded-runtime evidence - #566
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (13)
📝 WalkthroughWalkthrough패치 검증기 이미지는 검증된 c-ares 1.34.8 소스를 사용합니다. 런타임 적용성 필터가 V8, SQLite, zlib 발견을 처리합니다. 이미지 빌드는 Changes패치 검증기 런타임 및 빌드
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Workflow as patch-validator-image.yml
participant Action as docker/build-push-action
participant Dockerfile as Dockerfile.patch-validator
participant Image as 패치 검증기 이미지
Workflow->>Action: 이미지 빌드 입력과 150분 제한 전달
Action->>Dockerfile: Dockerfile과 validator_deps 컨텍스트 사용
Dockerfile->>Image: c-ares 1.34.8 소스 검증 및 Node 이미지 생성
Image-->>Workflow: 로드된 이미지와 이미지 태그 반환
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
seonghobae
changed the title
seonghobae
changed the title
seonghobae
left a comment
seonghobae
left a comment
There was a problem hiding this comment.
Fresh security review found a source-provenance defect in the c-ares repair: extracting 1.34.8 over Node's existing deps/cares directory could retain files that existed only in the vendored 1.34.6 tree, yielding a mixed source tree despite the new tarball checksum. Test-first commit 6c84bc0dabc948241d593ae57514e12984b75626 adds a regression requiring full replacement before extraction; its hosted runs were cancelled by the subsequent source push under cancel-in-progress, but the pre-fix Dockerfile at that exact head demonstrably lacked both cleanup operations. Causal fix 050ab45ae9b28a1f8f043e3a62d3b97c86c24d73 now removes and recreates /usr/src/node/deps/cares before extracting the checksum-authenticated 1.34.8 tree. Require fresh exact-head four-GREEN; no earlier gate transfers.
1 participant
Reality RED → causal repair chain
This Draft remains the patch-validator image/cache/static-runtime receipt lane. It does not own scanner authority, quarantine/outbound policy, LLM provider routing, or release authority.
Protected
main@be7df559ca8c1d81b61f68f68c36d1526c94e7f2already contains #569's Vitest 4.1.11 and explicit WASI platform binding. #566 was ordinary/non-force reconverged onto that protected source and retained its original authenticated BuildKit GHA cache repair.Authenticated cache proof
Current-base run
34327281657/ job102387341214proved the original cache defect repaired: exact-pinneddocker/build-push-action@d08e5c354a6adb9ed34480a06d141179aa583294imported the authenticatedtype=ghamanifest, reported the expensive Node/OpenSSL build stagesCACHED, exported the cache, and completed the build-action step in about 10 seconds. Image build, static inspection, no-network/read-only/non-root smoke, SBOM and scanners then ran normally.Secondary RED 1 — normalized V8 CPE artifact version
That run exposed the strict verifier's raw-version/CPE-version mismatch.
eb546862d1d25bfe86410dd495a3885941c42cc5andb1c33d1c0d3ff0dc6d3d5fae6d4d8dd1ea56270drepair it narrowly: PURL artifacts retain exact component versions; CPE artifacts must use the version encoded in the already reviewed exact CPE identity. Patched Node V813.6.233.17-node.51therefore accepts only reviewed CPE/scanner version13.6.233.17, while scanner target, name, identity and provenance remain exact and malformed CPEs fail closed.Secondary RED 2 — actual vulnerable component versus scanner applicability
With that verifier repair active, exact
b1c33d...run34328891694/ job102392538446again proved cache import/hit/export, exact image/runtime/smoke/SBOM/scanner stages and then failed at final receipt verification. Retained artifact10095371779, digestsha256:21d9d7a7403ae4be1af21b4a769baa23d77714b2239cbc4c7975ac498728c7b4, separates the findings:CVE-2026-33630is applicable. Upstream 1.34.7 is the security release and 1.34.8 retains the fix while restoring callback API compatibility. Current source uses official c-ares 1.34.8 (sha256:c222b6d681096f9444d2c4863d2c1174019e27cacca0a4a5c114d36dd7d7bf78) in Node 24.19.0's vendored integration and requires the built binary to reportprocess.versions.ares === "1.34.8". The finding is repaired, not suppressed.BIT-sqlite-2024-0232,BIT-sqlite-2025-29088, andBIT-sqlite-2025-6965; reviewed affected ranges end at 3.43.1, 3.49.0, and 3.50.1 respectively. Exact 3.53.3/NVD-CPE matches are therefore derived applicability exclusions only; all other SQLite findings stay blocking.GHSA-g857-hhfv-j68wis aruby/zlibRubyGemsZlib::GzipReaderadvisory, not an upstream C-zlib advisory. The exact Node embedded C-zlib CPE may exclude only that finding with exact Grype/NVD-CPE provenance.CVE-2026-85046is tied by the primary V8 fix to the inlinedArray.prototype.sortreducers. The exact signed Node 24.19.0 release commitcdc1b38d40cb567b7ad0b39c86addf830a0af0aecontains neither affected reducer in its vendored V8 source. The generic V8 CPE result may therefore be excluded only for exact Node 24.19.0 / V813.6.233.17-node.51/ reviewed CPE / normalized scanner version / Grype 0.116.1 provenance. A version, component, scanner, CPE or finding mismatch remains blocking.Secondary RED 3 — c-ares release payload lost Node's Linux build config
Fresh exact
19f74d217a19af03e95f8ee5eebff45e5defa549run34344126471/ job102441610182did not reach the receipt verifier. The retained BuildKit record artifact10101340696reproduces the actual compiler failure: Node's c-ares integration reachesdeps/cares/src/lib/ares_setup.hand cannot includeares_config.h. Node 24.19.0's canonicaldeps/cares/cares.gyprequiresconfig/linuxandconfig/linux/ares_config.h; the source-replacement lane therefore had to preserve that Node-owned generated integration data rather than merely copy it into a possibly pre-existing release-treeconfigdirectory.Test-first commit
e8fb138d2b1167546d0d444cac40ce2635e0194emakes the Dockerfile contract require explicit replacement of the reviewed release tree'sconfigpath plus a post-install Linux-config assertion. Causal fix772bfba546d75ed2495d57ce43d3d390230b85fenow removes/tmp/cares-reviewed/config, restores the exact Node-owned config atomically, installs the reviewed c-ares sources, and fails before compilation unless/usr/src/node/deps/cares/config/linux/ares_config.hexists. This repairs the integration input; it does not suppress c-ares scanning or weaken the final provenance verifier.Fresh primary-source review additionally verified:
c-ares-1.34.8.tar.gzrelease asset carries GitHub-published digestsha256:c222b6d681096f9444d2c4863d2c1174019e27cacca0a4a5c114d36dd7d7bf78;deps/cares/cares.gyprequiresconfig/linux/ares_config.hon Linux;tools/dep_updaters/update-c-ares.mjsderives the GYP source list from c-aressrc/lib/Makefile.incplus public headers;src/lib/Makefile.incsource/header list, so retaining the Node-generated GYP source list while replacing the reviewed source payload does not silently omit a new 1.34.8 compilation unit.The applicability decisions and primary-source traceability remain in
docs/doctoring/patch-validator-embedded-runtime-applicability-2026-09-09.md. Focused regressions exercise exact finding/component/CPE/scanner bounds and fail-closed mismatches.Current exact-head acceptance
Current exact is
772bfba546d75ed2495d57ce43d3d390230b85fe, Draft on protectedmain@be7df559ca8c1d81b61f68f68c36d1526c94e7f2.34347187052: SUCCESS34347186941: SUCCESS34347187127: SUCCESS34347186922/ job102451469711: IN_PROGRESS, assigned to GitHub-hostedubuntu-24.04; checkout, stale-head refusal, dependency materialization and Buildx setup are GREEN; current step isBuild exact-head patch-validator image with authenticated GitHub Actions cache.No predecessor GREEN is transferred. Do not rerun unchanged source merely to alter queue/build time. Require the unchanged exact to obtain terminal patch-validator-image GREEN plus clean review/current-base verification before normal integration; Draft remains appropriate until then.
Summary by CodeRabbit
개선 사항
문서
테스트