ci: vendor governance-enforce — this repo was never in the A_BLOCK ruleset - #62
ci: vendor governance-enforce — this repo was never in the A_BLOCK ruleset#62yakimoto wants to merge 3 commits into
Conversation
…never in the ruleset
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 44 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. 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: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_6fda7d5e-4720-463f-b48e-8be42606bb1f) |
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Needs human review Unable to check for correctness in 2c40f4a. An unresolved critical review comment identifies a gap in the force-push fallback logic where multi-commit pushes may only scan the final commit, allowing the security gate to pass without examining all changes. This contradicts the stated fail-closed invariant and warrants review before merge. You can customize Macroscope's approvability policy. Learn more. |
PR Summary by QodoCI: vendor governance-enforce A_BLOCK diff gate for secrets/hardcoded paths
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| - name: fetch governance enforcer (isolated install) | ||
| run: | | ||
| mkdir -p "$RUNNER_TEMP/gov" && cd "$RUNNER_TEMP/gov" | ||
| printf '@wave-av:registry=https://npm.pkg.github.com\n//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}\n' > .npmrc | ||
| npm install @wave-av/governance@^0.4.4 --no-save --no-audit --no-fund |
There was a problem hiding this comment.
🔍 Fork PRs may not be able to install the private @wave-av/governance package
The isolated install authenticates to npm.pkg.github.com with secrets.GITHUB_TOKEN and packages: read. For pull requests from forks, the workflow token is read-only and scoped to the fork's repository context; if @wave-av/governance is a private/internal GitHub Packages artifact, npm install will 401/403 and this job will fail for every external contributor PR. Worth confirming before adding the check to the governance-a-block-enforce ruleset, since a permanently red required check on fork PRs blocks outside contributions to this public repo.
Was this helpful? React with 👍 or 👎 to provide feedback.
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Qodo FixerNo findings are within the configured fix scope. To change which findings are fixed, adjust the setting on your Qodo configuration page. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…othing Five defects, none of them cosmetic. Refs wave-av/claude-workstation#1747. 1. FAIL-OPEN DIFF BASE. `BASE=$(git rev-parse HEAD~1 2>/dev/null || git rev-parse HEAD)` — on a root commit `git rev-parse HEAD~1` prints its unresolved argument to stdout AND fails, so the `||` branch appends and BASE becomes a two-line string. `git diff` then exits 128, and the pinned enforcer turned that into zero files and a green check. Now: a reachability-checked base (a force-push can leave `github.event.before` pointing at a commit this checkout does not have), and with no resolvable base at all it diffs against the EMPTY TREE so the whole repo is scanned rather than nothing. 2. THE PINNED ENFORCER ITSELF FAILED OPEN. `^0.4.4` resolved to 0.4.4, whose file lister is `catch { return []; }` — any git error became zero files and rendered as `OK[enforce]: 0 changed file(s) scanned — 0 A_BLOCK violations`. A git error and a clean diff were byte-identical in the output. The fix had sat unreleased on claude-workstation main since 2026-07-29 because no `governance-v*` tag was ever pushed. Released now as 0.4.6 and pinned exactly here. 3. TOKEN IN SCOPE FOR THE WRONG STEPS. `NODE_AUTH_TOKEN` was job-level, so it was also in the environment of the step that executes the downloaded package. Now step-scoped, and the .npmrc holding it is removed on exit. 4. INSTALL SCRIPTS RAN WITH THAT TOKEN. `npm install` runs preinstall/postinstall by default. Added `--ignore-scripts`. 5. CANCELLED PUSH RUNS WERE SCANNED BY NOBODY. `cancel-in-progress: true` applied to push runs, and each push run only diffs its own before..HEAD range — so a cancelled run's commits were never examined by anything. Now PR-only. Also: `timeout-minutes: 10` and `set -euo pipefail`. Receipt, against a scratch repo whose root commit carries a no-hardcoded-paths violation, simulating a branch-creation push (`before` = all zeros): old logic -> malformed base -> caught error -> [] -> OK, 0 files scanned, PASS new logic -> "no diff base resolved ... scanning the whole tree" -> BLOCK, exit 1 Credit where it is due: several of these were found by the review bots on the sibling vendoring PRs and are folded in here — the step-scoped token, the .npmrc cleanup, the exact pin, `--ignore-scripts`, the force-push reachability check, `timeout-minutes`, and the concurrency hole (5), which was crest-console#7's catch and which I had missed entirely.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_410fccd4-7fbf-42ec-ad5e-306aaa1f3ce9) |
| if [ -z "$BASE" ]; then | ||
| BASE="$(git hash-object -t tree /dev/null)" | ||
| echo "::notice::no diff base resolved (root commit or unreachable before-sha) — scanning the whole tree against the empty tree" | ||
| fi | ||
| echo "diffing against $BASE" | ||
| exec node "$ENFORCE" --changed "$BASE" |
There was a problem hiding this comment.
🔍 Empty-tree fallback assumes the enforcer accepts a tree object as its diff base
When no base commit resolves, BASE is set to the empty-tree hash (git hash-object -t tree /dev/null) and passed as --changed "$BASE". This only works if @wave-av/governance@0.4.6's file lister performs a two-dot/tree-vs-worktree diff (git diff --name-only <base>). If it instead uses a three-dot range (git diff --name-only <base>...HEAD) or validates the argument with rev-parse <base>^{commit} (as this workflow itself does at .github/workflows/governance-enforce.yml:79), the tree hash will make git error out and the fail-closed path would abort rather than scan the tree. Worth confirming against the package's bin/enforce.mjs implementation before relying on this branch.
Was this helpful? React with 👍 or 👎 to provide feedback.
| BASE="$(git rev-parse --verify --quiet 'HEAD~1' || true)" | ||
| fi | ||
| # FIX 5 — fail CLOSED. This previously fell back to `BASE=HEAD`, and `--changed HEAD` | ||
| # diffs HEAD against itself: an empty diff, zero files scanned, job green. With no | ||
| # resolvable base, diff against the EMPTY TREE so every tracked file reads as added and | ||
| # the whole repo is scanned. (`--all` also exists in 0.4.6 and would do most of this, but | ||
| # it is documented as NOT covering the diff-scoped over-grant detectors. Routing through | ||
| # the diff path with an empty base keeps every detector in play.) | ||
| if [ -z "$BASE" ]; then |
There was a problem hiding this comment.
🔴 Critical workflows/governance-enforce.yml:80
When github.event.before is unreachable (e.g. a force-push), the fallback at line 80 resolves BASE to HEAD~1. On a multi-commit push this diffs only the final commit against its parent, so violations introduced by earlier commits in the same push are never scanned — the gate can pass while leaving most of the push unexamined. The fallback should stay fail-closed: fall through to the empty-tree case unless a trustworthy range base is available.
BASE="$(git rev-parse --verify --quiet 'HEAD~1' || true)"
- fi
- # FIX 5 — fail CLOSED. This previously fell back to `BASE=HEAD`, and `--changed HEAD`
- # diffs HEAD against itself: an empty diff, zero files scanned, job green. With no
- # resolvable base, diff against the EMPTY TREE so every tracked file reads as added and
- # the whole repo is scanned. (`--all` also exists in 0.4.6 and would do most of this, but
- # it is documented as NOT covering the diff-scoped over-grant detectors. Routing through
- # the diff path with an empty base keeps every detector in play.)
- if [ -z "$BASE" ]; then🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @.github/workflows/governance-enforce.yml around lines 80-88:
When `github.event.before` is unreachable (e.g. a force-push), the fallback at line 80 resolves `BASE` to `HEAD~1`. On a multi-commit push this diffs only the final commit against its parent, so violations introduced by earlier commits in the same push are never scanned — the gate can pass while leaving most of the push unexamined. The fallback should stay fail-closed: fall through to the empty-tree case unless a trustworthy range base is available.
Evidence trail:
.github/workflows/governance-enforce.yml:42-45, 67-93 (commit 73a72cfd); `git blame REVIEWED_COMMIT -L 74,91 -- .github/workflows/governance-enforce.yml`
…l a false pass Correction to the previous commit on this branch. Refs wave-av/claude-workstation#1747. That commit replaced the fail-open `BASE=HEAD` with a fallback to `HEAD~1`. `HEAD~1` is also wrong: it scans exactly ONE commit, so a five-commit push whose base is indeterminate (branch creation, force-push, unreachable `github.event.before`) examines the last commit and reports a confident pass on the other four. A narrowed scan reported as a full pass is the same defect in a quieter costume. Receipt — scratch repo, five-commit push, violation planted in commit 1: HEAD~1 base -> OK[enforce]: 1 changed file(s) scanned -> PASS (never saw it) empty-tree base -> 5 changed file(s) scanned -> BLOCK[enforce]: no-hardcoded-paths, exit 1 Now: with no resolvable base of any kind, diff against git's empty-tree object so every tracked file reads as added and the whole repo is scanned. Loud, never partial, never empty. Credit: wave-av/wave-rig's copy on main already had this right, with the reasoning in a comment ("HEAD~1 would skip earlier commits in a multi-commit push and let a violation through"). The fan-out copied the broken shape from elsewhere and I did not check the one repo that had already solved it. Also from wave-rig: `merge_group` is now a declared trigger and `github.event.merge_group. base_sha` joins the base chain. None of these repos runs a merge queue today, so the trigger is inert — but a required check that never reports on an event the repo actually uses is a permanent deadlock, and this closes that in advance rather than after someone hits it.
| - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3 | ||
| with: | ||
| fetch-depth: 0 | ||
| persist-credentials: false | ||
| - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0 | ||
| with: | ||
| node-version: "22" |
There was a problem hiding this comment.
🔍 Action pin versions differ from the rest of the repo's workflows
Other workflows here pin actions/checkout at v4.3.1 (34e114876b...). This new file pins a different SHA labeled v6.0.3, and actions/setup-node labeled v6.4.0. The SHAs cannot be verified from the repo; if a label/SHA mismatch exists the pin comment becomes misleading. Consider aligning pins across workflows or documenting why this one differs.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Adds the
governance-enforceA_BLOCK gate (secrets / hardcoded-paths, diff-scoped) to this repo. Part of claude-workstation#1624 E4 T4.9a, following thewave-av/cli#20pilot.Why this repo had no secrets scan
The org ruleset
governance-a-block-enforce(17901847) requires anenforcecheck across the fleet. Its scope is an explicit include list of 112 hand-maintained repository names — and every one of them matcheswave-*.The 16 public repos absent from that list are exactly the 16 not named
wave-*:.github,adk,api-spec,cli,companion-module-wave,create-wave-app,crest-console,dispatch-edge,examples,mcp-server,obs-wave-plugin,sdk,sdk-python,sdks,vmix-wave-integration,workflow-sdk.Read the intersection: the repos that publish our npm packages are precisely the repos running with no A_BLOCK secrets scan. Nobody excluded them. A naming convention silently became a security boundary, and it drew the line in the worst possible place.
Why the workflow lands before the ruleset entry
Adding a repo to a
required_status_checksruleset before it emits that check is a permanent deadlock — a required check that never reports can never go green, and every PR on the repo becomes unmergeable. So the order is: vendor the workflow, observe it green, then extend the list. Doing it the intuitive way round would have bricked all sixteen.This PR is also its own liveness drill. The workflow triggers on
pull_request, so it runs on the PR that adds it. Ifenforcereports green here, the vendored shape works in this repo. If it does not, nothing was required and nothing is blocked — which is the point of this ordering.Proven before fan-out, not assumed
@wave-av/governanceis aninternal-visibility package owned byclaude-workstation, so whether a public repo'sGITHUB_TOKENcan read it was the one real assumption. Rather than fan out on the inference, it was piloted on a single repo first:That is the receipt this PR rides on. The shape is copied verbatim from
wave-av/wave-moq-edge(public, 12/12 green), which matters becauseauto-approve.ymlfails silently on every public repo — it calls a reusable workflow in the privatewave-foundation, and a public repo cannot do that (parse-time failure, zero jobs, no annotation). This workflow calls nothing cross-repo, so that trap does not apply.Security properties, unchanged from the source:
actions/checkout@df4cb1c,actions/setup-node@48b55a0)persist-credentials: falseon checkoutcontents: read+packages: readRUNNER_TEMP,--no-save, so nothing touches this repo's dependency tree.npmrcis written with a literal${NODE_AUTH_TOKEN}(single-quotedprintf) which npm expands at run time — no secret value is ever written to disk or a log${{ }}inputs (base.sha,event.before) are routed throughenv:and read as"$VAR", never interpolated into the script bodyDiff-scoped by design: it blocks new violations without failing on legacy debt.
Refs wave-av/claude-workstation#1624.
Note
Low Risk
CI-only addition with read-only repo permissions and an isolated npm install; no application or release artifact changes.
Overview
Adds
governance-enforce.yml, bringing this npm-publishing repo under the same A_BLOCK gate (secrets-in-git, Doppler expectations, hardcoded paths) that org rulesets already require onwave-*repos. Scans are diff-scoped so new violations fail CI without blocking on legacy debt.The job installs
@wave-av/governance@0.4.6intoRUNNER_TEMP(not the repo tree), runsenforce.mjs --changed, and emits theenforcestatus check intended forgovernance-a-block-enforceonce this workflow is green here first.Hardening baked into the vendored copy: registry token only on the install step,
--ignore-scripts, exact package pin, push concurrency that does not cancel overlapping push runs (so commits are not skipped), and fail-closed base resolution (empty tree full scan when no diff base exists, instead of a silent zero-file pass).Reviewed by Cursor Bugbot for commit 73a72cf. Configure here.
Note
Add governance enforcement workflow to scan diffs on PRs and pushes to main
Adds governance-enforce.yml, which runs
@wave-av/governance@0.4.6on pull requests, merge groups, and pushes to main/master. The enforcer scans only changed files using a computed diff base; if no valid base is found, it falls back to the empty tree and scans the full repository. Push and merge group runs are not cancelable to ensure no committed ranges are skipped.Macroscope summarized 2c40f4a.