Untrusted PR Gate
RStack ships code that runs inside its users’ development environments — its workflows run with repository credentials, itspackage.json lifecycle scripts execute on every npm install, and its harness core gates real approvals and budgets. A malicious or careless change to any of those, landed through an ordinary-looking PR, is a supply-chain incident for every downstream user (the risk class NIST SSDF SP 800-218 and SLSA exist to reduce).
The untrusted PR gate (#75) draws that boundary explicitly: contributors outside the maintainer trust circle can freely improve docs, tests, and examples, but changes to protected paths or risky content patterns are blocked or routed to maintainer review.
How it works
.github/workflows/rstack-untrusted-pr-gate.ymlruns onpull_request_targetand is safe under it by construction: it checks out the base branch only (PR code never executes), installs no dependencies, and reads the PR’s changed files and patch text through the GitHub API.src/security/untrusted-pr-gate.jsis the pure evaluator — author trust + changed files in, verdict + findings out. Trust comes fromauthor_association(OWNER / MEMBER / COLLABORATOR are trusted); no hardcoded usernames.- Verdict ladder:
allow<needs-maintainer-review(label applied, check passes) <block(check fails).
What gets flagged for untrusted authors
A gate evaluation failure also fails the check — the gate fails closed.
Configuration
.rstack/security/untrusted-pr-gate.json, shallow-merged over the defaults:
For maintainers
Ablock verdict is not a judgment of the contributor — it means the change needs your hands: review the diff, then either push the change yourself or, if your platform trust allows it, re-run after adjusting the config. needs-maintainer-review PRs get the label applied automatically and pass the check, so docs-adjacent contributions are never stalled on red CI.
