fix: Harden CLI distribution and Unity IPC security#1794
Conversation
|
Warning Review limit reached
Next review available in: 8 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (8)
📒 Files selected for processing (88)
✨ Finishing Touches🧪 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 |
Summary
This integration hardens CLI distribution, first installation, security scanning, and Unity IPC before release to
v3-beta.Finding 1: Bootstrap provenance (PR-2)
Previous behavior
The CLI-only and Unity installation paths could rely on same-origin checksums or mutable branch installer URLs, and the installer archive attestation manifest was optional.
Root cause
Integrity checks were not an authenticated trust root, and bootstrap inputs were not bound to one immutable dispatcher release and its verified subjects.
Fix
The package stores a CI-verified dispatcher release tag and canonical archive manifest in the pin. CLI-only bootstrap obtains the installer and its Sigstore bundle from that immutable release, derives the archive manifest from the verified bundle, and fails closed when verification material is absent or invalid. The installer verifies the archive and bundle before extraction or execution. Mutable
curl | sh/irm | iexpaths and checksum-only authentication are removed.Attack conditions addressed
A substituted installer, archive, release tag, source identity, subject digest, malformed bundle, missing verifier input, or unavailable GitHub API cannot reach script or binary execution.
Test evidence
Pin reader/stamp/guard tests, installer manifest tests, workflow static tests, bootstrap bundle fixture, and exact-head CI are green. See PR #1791.
Residual risk
First installation requires network access and a GitHub CLI for the CLI-only path; offline bootstrap is unsupported. The package-local Unity path uses the CI-stamped SHA-256 manifest and does not require external
gh.Finding 2: Fail-closed C# security scanning (PR-3)
Previous behavior
The security workflow could create or accept placeholder SARIF and did not reliably distinguish scanner failure, unusable analysis, or missing SARIF from a clean scan.
Root cause
Scanner execution, SARIF validation, quality checks, and upload were not enforced as one fail-closed sequence.
Fix
Pinned CodeQL
build-mode: nonesecurity-extended analysis now requires a real non-empty SARIF result. A Go guard validates SARIF schema, run count, tool identity, scanner status, and database quality floors; only verified SARIF reaches upload. C# quality floors are 55% call targets and 70% known types, with the 68%/82% PoC values exposed as non-blocking drift warnings.Attack conditions addressed
An attacker cannot turn scanner failure, compile/database degradation, missing output, malformed SARIF, or a false zero-finding result into a green security check.
Test evidence
Probe and failure regression tests, workflow static tests,
scripts/check-security-scan-workflow.sh,scripts/check-go-cli.sh, CodeQL SARIF validation, and exact-head CI are green. See PR #1792.Residual risk
The approved corpus is
Packages/srcplusAssets/Tests; repo-wide C# coverage and Unity-generated project reference precision remain future work requiring remeasurement and owner reapproval.Finding 3: Unix IPC user isolation and protocol generation 4 (PR-4)
Previous behavior
Unix IPC used a shared temporary endpoint boundary without sufficient owner, mode, symlink, and socket cleanup guarantees. Project resolution also validated the endpoint, breaking no-dial dispatcher commands when Unity had not created its directory.
Root cause
Endpoint protection was not consistently placed at the protected network operation, and the IPC rendezvous change required an explicit contract generation bump.
Fix
Both Unity and Go use
/tmp/uloop-<effective UID>. The parent is checked through symlink resolution for root ownership and sticky mode; the endpoint directory is checked without following links for current-user ownership and exact0700; sockets are restricted to0600. Validation is performed at one client dial choke point, while project/pin/cache/help/version resolution remains usable without a running Unity endpoint. A restriction failure callsStop()so a bound socket is closed and removed. The IPC protocol pair is bumped from 3 to 4 in one commit.Attack conditions addressed
Other OS users cannot precreate, replace, or redirect the endpoint directory/socket to intercept or deny another user’s IPC. Untrusted replacement paths are never deleted, and failed validation never reaches a network dial.
Test evidence
Red-to-Green socket-cleanup regression, Unity compile with 0 errors/0 warnings, focused EditMode tests, Go tests/lint/vet/build, Windows/Linux cross-compilation, release trigger and dispatcher pin guards, and exact-head CI are green. See PR #1793.
Residual risk
A process running as the same OS user remains within the trust boundary. Protocol 4 requires release ordering before the package pin can advance.
PR-5 decision
Repository owner decision on 2026-07-15 cancels To-Do 25–28. This individual OSS project will not purchase Apple Developer, Authenticode, or Trusted Signing infrastructure. Free Sigstore attestation already covers every release asset, including beta releases; OS-native signing remains optional defense-in-depth and is not a prerequisite. No signing credentials or signing workflow changes are included.
Release ordering
Protocol 4 must be advertised by a project runner release first. Release-please then advances the project runner pin, followed by the Unity package release.
check-protocol-minimum-versionis expected to remain red for the interval before the runner release and pin advance; manually dispatched workflows without a PR diff skip that diff-dependent check.Verification
06fcced00e5038d7dcf09588b08bdfc453c02f19scripts/check-go-cli.shandscripts/build-go-cli.sh— green