Repository navigation
fix(drift-audit): mint the publish-bot App token so the audit can read the org - #1194
Merged
Merged
Conversation
…d the org
The audit ran on GITHUB_TOKEN, which is scoped to displayxr-runtime alone.
That silently degraded every cross-repo READ against a private sibling --
displayxr-shell-pvt resolved to "could not fetch ... skipped" notes rather
than findings, so a whole repo was effectively unaudited in CI while it
audited fine from a developer's own gh auth. (That is why the stale vendored
spec there was visible locally but never in a run.)
The publish-bot App is installed org-wide (repository_selection=all) with
contents:write, so an installation token scoped with `owner:` and no
`repositories:` covers every repo the audit touches. Strictly better reads,
no new secret, nothing to expire -- unlike a PAT, which is the same
rot-by-expiry shape as the bugs this audit exists to catch.
This does NOT by itself restore per-repo issue emission. The App's
permissions are {actions:read, contents:write, metadata:read} -- it has no
`issues` scope at all, which is why wiring it earlier would not have helped.
Granting the App `issues: write` and approving it on the org installation is
the one remaining step, and needs no further change here: emission starts
working the moment the permission exists. Until then it falls back to the
aggregate issue on this repo and says so loudly.
Precedence is PAT > App token > GITHUB_TOKEN, so setting DRIFT_AUDIT_TOKEN
still overrides. The mint step is continue-on-error: a token hiccup degrades
to GITHUB_TOKEN rather than failing the audit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ua8CevgSHNqoyiy7ziZjHk
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1185. That PR made the audit's writes honest; this one fixes its reads.
The read gap
The audit ran on
GITHUB_TOKEN, scoped todisplayxr-runtimealone. Every cross-repo read against a private sibling silently degraded —displayxr-shell-pvtresolved tocould not fetch … skippednotes instead of findings, so a whole repo was effectively unaudited in CI while auditing fine from a developer's ownghauth.That is precisely why the 3-month-stale vendored spec there was visible when I ran the audit locally but had never appeared in a scheduled run.
Why the App token, not a PAT
The publish-bot App is installed org-wide (
repository_selection=all) withcontents:write, so an installation token scoped withowner:and norepositories:covers every repo the audit touches. No new secret, and nothing to expire — a PAT is the same rot-by-expiry shape as the bugs this audit exists to catch.Precedence stays
DRIFT_AUDIT_TOKEN> App token >GITHUB_TOKEN, so an explicit PAT still overrides. The mint step iscontinue-on-error, so a token hiccup degrades rather than failing the audit.What this does NOT fix — and the one step that does
Issue emission still cannot work per-repo. The App has no
issuesscope at all:which is also why wiring the App earlier would not have helped.
The remaining step is yours: grant
displayxr-publish-bottheissues: writepermission and approve it on the org installation. No further code change is needed — per-repo emission starts working the moment the permission exists. Until then findings land as one aggregate issue on this repo, loudly, per #1185.Verified
YAML parses; step ordering correct. The token's effect on reads can only be confirmed by a real scheduled run — I can't mint an installation token locally.