Skip to content

docs(ci-setup): the required "Allow GitHub Actions to create and approve pull requests" setting weakens a ≥1-approval ruleset #653

Closed

Description

@goosewobbler

Problem

The standing-PR template (templates/workflows/standing-pr.yml:4-8) and packages/release/docs/ci-setup.md require the repository setting "Allow GitHub Actions to create and approve pull requests". GitHub ties creating and approving PRs to that one toggle, so with it on, any workflow's GITHUB_TOKEN can submit an approving review — including a workflow a write collaborator adds on their own branch.

That approval counts toward the ruleset ci-setup.md recommends as the merge gate — "Require a pull request before merging (≥ 1 approval)" on the default branch — for any PR not authored by github-actions[bot]. A feeder PR approved that way then ships in the next standing-PR release, whose own diff shows only version and changelog changes.

Proposal

  1. Document the trade-off next to the setup requirement.
  2. Recommend pairing the default-branch ruleset with required Code Owners review (or required team reviewers), which a workflow token can't satisfy. The CODEOWNERS file needs a * rule naming an owner with write access, and the ruleset should also dismiss stale approvals when new commits are pushed. None of it applies to bypass actors (Standing-PR setup: bypasses for the Actions bot and workflow-wide id-token: write reach every workflow #785).
  3. Document creating the standing PR with a GitHub App token (e.g. actions/create-github-app-token) so the toggle can stay off. Dropped: the App's key would be a repository secret, which any workflow on any branch can read, so a collaborator's workflow could mint an App token and approve their own PR.
  4. Optionally, recommend binding npm trusted publishing and registry secrets to a deployment environment restricted to the default branch — the template's publish job sets no environment:. A merged PR's closed run has the branch it merged into as its ref, so the merge-triggered publish jobs pass. A label-triggered retry may not.

Related: #619 (agent guidance already cautions against relying on "≥ 1 approval" alone).

Items 1, 2 and 4 are done in #758. The template's other least-privilege gaps are tracked in #785.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions