Repository navigation
chore(quest): plan read-only pull-request CI - #7116
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 20 minutes. View limit details
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 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f3c636abd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| `APP_PRIVATE_KEY` and `DISCORD_WEBHOOK`. The App key can write, so scope it | ||
| the same way, or create its token only in jobs gated to a protected | ||
| environment. |
There was a problem hiding this comment.
If the organization-level APP_PRIVATE_KEY remains accessible to this repository, gating the existing token-creation jobs behind an environment does not protect it from an unreviewed same-repository branch. That branch can add its own workflow referencing the organization secret and mint a write token without using the gated job, just as .github/workflows/release-rs.yml currently mints one with actions/create-github-app-token. Remove token-creation gating as an alternative to secret isolation: the plan must require removing this repository's access to the organization-level key and supplying it only through a protected environment.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Agreed: a visible organization secret can be read by any workflow a branch adds, so gating the token-minting jobs does not protect it. Fixed in fc50673: the plan now requires removing this repository's access to the organization APP_PRIVATE_KEY and supplying the key only through a protected environment.
(written by Claude Opus 5.5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kixelated
left a comment
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 9f3c636abdc719d08c9b0e8b70630042e878f6dd.
The direction is sound: isolate write credentials in protected environments and distinguish genuinely read-only cache credentials from a client's read-only mode. One actionable plan flaw remains, already reported independently in this finding: quest/m0/ci/read-only-secrets.md:37–39 must require isolating the organization App private key itself, not offer gating existing token-creation jobs as an alternative. An unreviewed branch can mint its own token while the key remains available. I confirmed the current release workflow consumes that key directly; no duplicate inline comment added. No additional actionable findings in the changed plan.
Verification: inspected the documentation diff, release workflow, related cache plan and existing review. Did not run tests or a probe workflow, inspect live secret/environment settings, or verify publisher trust policies; this planning PR does not itself enforce the intended boundary.
kixelated
left a comment
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: fc50673cae3f195722f4f2f3d04f3af936fbccee, compared with my previous review at 9f3c636abdc719d08c9b0e8b70630042e878f6dd.
Fixed in the plan: quest/m0/ci/read-only-secrets.md:36–40 now requires removing repository access to the organization App private key and providing it only through a protected environment, resolving the previously referenced P2. This is the right boundary; gating token-minting jobs alone is explicitly rejected. No new actionable findings in this focused update.
Verification: compared the single changed document and rechecked PR state/head/reviews. No tests or probe workflow run; live secret isolation, environment policies and publisher trust were not verified. The documentation fix is not evidence that those operational changes are deployed.
|
Merge summary:
(written by Claude Opus 5.5) |
Plans Read-only pull-request CI [S], ranked first in the CI epic.
Why
Agents and the kix.quest App push branches to this repository itself. GitHub hands a branch's workflows the repository's secrets, so unreviewed code can reach write credentials unless pull-request CI stays read-only.
kixelated/quest's trust audit made read-only CI the rule for every repository enrolled in kix, and moq-dev/moq is a pilot repository. The audit found that this repository breaks the rule today:
CARGO_REGISTRY_TOKEN,CLOUDFLARE_API_TOKEN,APP_PRIVATE_KEYandSIGNING_KEY.pub.devandpypienvironments have no deployment branch policy, so any branch can claim the OIDC identity a registry may trust.Decisions (maintainer, 2026-10-28)
moq-dev/moq's repo-level write secrets
Rank in
quest/m0/ciChecks
quest checkpasses (618 documents).🤖 Generated with Claude Code
(written by Claude Opus 5.5)