Skip to content

fix(security): redact main-governance child token diagnostics - #137

Open
seonghobae wants to merge 2 commits into
mainfrom
fix/main-governance-diagnostic-redaction
Open

fix(security): redact main-governance child token diagnostics#137
seonghobae wants to merge 2 commits into
mainfrom
fix/main-governance-diagnostic-redaction

Conversation

@seonghobae

@seonghobae seonghobae commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Purpose

Test-first repair for #136. The main-governance audit already narrows GitHub CLI child authority, but a failing child could echo the delegated GH_TOKEN into retained failure diagnostics. This line removes the exact delegated token before diagnostics are bounded or persisted.

Exact current identity

  • protected/live base: main c85d710804139c0697d7ef8fa47d02b1389e6d84;
  • branch: fix/main-governance-diagnostic-redaction;
  • RED head: 59dd374799efe83c592ab23aab9acd18dd4e0c3f;
  • GREEN/current head: f4d7f6471f00de55a8e3354750b5703460e2c780;
  • current compare: 2 commits ahead / 0 behind main, merge base exactly the live protected head;
  • changed paths: scripts/main-governance-audit.mjs, test/main-governance-audit-script.test.ts.

RCA -> RED -> GREEN

The first failing boundary was GitHub CLI failure output -> retained governance diagnostics. runGh() bounded child startup/non-zero text but did not remove the short-lived delegated token first. The narrow repair now constructs the GitHub CLI child environment explicitly, pins GH_HOST=github.com and NO_COLOR=1, retains only optional non-empty PATH plus explicit GH_TOKEN, and redacts the exact delegated token from startup and non-zero diagnostics before bound() can feed report/summary/stdout evidence.

The hostile-parent regression proves ambient GITHUB_TOKEN, model/provider/App private material, Cloudflare credentials, proxies, HOME, NODE_OPTIONS, and unrelated state do not cross the child boundary. Existing API version, pagination, timeout/max-buffer, shell-free execution and fail-closed governance evaluation remain unchanged.

Exact current-head proof

For unchanged current head f4d7f6471f00de55a8e3354750b5703460e2c780:

  • application ci 31451862463: terminal success;
  • reviewer-ci 31451862443: terminal success;
  • eligible central Security Scan 31451862447: terminal success;
  • current inline review threads: 4 resolved / 0 unresolved;
  • visible formal review: one COMMENTED submission from github-code-quality, no qualifying APPROVED review;
  • GitHub reports the PR Ready and mergeable.

A CodeRabbit review request was rate-limited on this exact base/head. That is transient model/review evidence and is not promoted to approval or a passing gate.

Authority boundary

This repair hardens child-process authority and retained diagnostics only. It does not prove the live main ruleset, create an eligible independent reviewer, modify workflow permissions, publish a release, deploy Noema, choose an outbound license, establish production KPI/revenue/transfer evidence, or make an acquisition-readiness claim. Technical GREEN is not merge authority; #27/#29 retain the live governance and qualifying independent-review boundary.

Related: #27, #29, #90, #106, #136

@coderabbitai

coderabbitai Bot commented Aug 11, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 754a02d6-e4ad-4306-8fc3-8343855070c5

📥 Commits

Reviewing files that changed from the base of the PR and between c85d710 and f4d7f64.

📒 Files selected for processing (2)
  • scripts/main-governance-audit.mjs
  • test/main-governance-audit-script.test.ts

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Comment thread test/main-governance-audit-script.test.ts Fixed
Comment thread test/main-governance-audit-script.test.ts Fixed
Comment thread test/main-governance-audit-script.test.ts Fixed
Comment thread test/main-governance-audit-script.test.ts Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant