chore(guard): sync vendored public-repo-guard to canonical - #23
chore(guard): sync vendored public-repo-guard to canonical#23wave-av-release-bot[bot] wants to merge 1 commit into
Conversation
|
PR author is in the excluded authors list. |
ApprovabilityVerdict: Needs human review Unable to check for correctness in 0d27c75. This is a straightforward CI security hardening (actions/checkout version bump + persist-credentials: false), but the file is owned by yakimoto while the author is a bot that doesn't own it. The designated code owner should review. You can customize Macroscope's approvability policy. Learn more. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 | ||
| with: | ||
| # Checkout defaults to persisting the job token for later steps: since v6 it | ||
| # lives in a file under $RUNNER_TEMP referenced from .git/config, no longer in | ||
| # .git/config itself. It is still a live credential in the job, and this job | ||
| # downloads a third-party binary (gitleaks, below) and runs it over the whole | ||
| # tree. Nothing here pushes -- the scan is `--no-git` over the working tree -- | ||
| # so no step needs authenticated Git; drop it. (zizmor: artipacked) | ||
| persist-credentials: false |
There was a problem hiding this comment.
🟡 Security gate template handed to other repositories still uses the old, less-safe checkout settings
The shared copy of the guard workflow that other repos install from was left on the old checkout version without the credential-dropping setting (actions/checkout@93cb6efe… # v5.0.1 at workflow-templates/public-repo-guard.yml:45), while only the in-repo copy was updated, so every repo adopting the template keeps the old behaviour.
Impact: New and existing repositories that copy this security gate continue to run with the job credential persisted, and the two copies drift apart.
Template/self-instance sync convention and the drift introduced here
Historically both copies are updated together (e.g. commit fb12a86 touched .github/workflows/public-repo-guard.yml and workflow-templates/public-repo-guard.yml in the same change). This PR only bumps the self-instance to actions/checkout@9c091bb… # v7.0.0 plus persist-credentials: false (.github/workflows/public-repo-guard.yml:45-53); diff between the two files now shows exactly that hunk as the only difference. Since the template is the distributable artifact for spokes, the hardening never reaches them.
Prompt for agents
The public-repo-guard workflow exists in two places that are conventionally kept byte-identical: .github/workflows/public-repo-guard.yml (the canonical self-instance) and workflow-templates/public-repo-guard.yml (the copy spokes install). This PR upgraded actions/checkout to v7.0.0 and added persist-credentials: false only in the self-instance, leaving the template pinned at v5.0.1 with credentials persisted. Apply the same checkout pin and persist-credentials: false (with the explanatory comment) to workflow-templates/public-repo-guard.yml so the two files stay in sync and downstream public repos get the hardening.
Was this helpful? React with 👍 or 👎 to provide feedback.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1 | ||
| - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 |
There was a problem hiding this comment.
🔍 Checkout SHA/version comment pairing should be confirmed by pinact
The pin 9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 cannot be verified offline. Prior commits in this repo (e.g. 0545008 "ci: exact version comment (v5.0.1) for pinact compatibility") show the SHA/comment pairing is machine-checked; worth confirming the SHA actually corresponds to the actions/checkout v7.0.0 tag before merge.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0 | ||
| with: | ||
| # Checkout defaults to persisting the job token for later steps: since v6 it | ||
| # lives in a file under $RUNNER_TEMP referenced from .git/config, no longer in | ||
| # .git/config itself. It is still a live credential in the job, and this job | ||
| # downloads a third-party binary (gitleaks, below) and runs it over the whole | ||
| # tree. Nothing here pushes -- the scan is `--no-git` over the working tree -- | ||
| # so no step needs authenticated Git; drop it. (zizmor: artipacked) | ||
| persist-credentials: false |
There was a problem hiding this comment.
🟨 Distributed guard template still persists job credentials during third-party binary execution
The PR removes the persisted job token in the repo's own guard workflow but leaves the spoke-facing template (workflow-templates/public-repo-guard.yml:45) on the old checkout pin without persist-credentials: false, so every repo installing the template keeps a live Git credential in the workspace while a downloaded third-party gitleaks binary is executed over the tree (the very risk the new comment in .github/workflows/public-repo-guard.yml:47-52 describes).
Was this helpful? React with 👍 or 👎 to provide feedback.
Syncs the vendored
public-repo-guardtrio to the canonical source inwave-foundation/scaffolder/public-repo-guard.internal-ipleak rule (Tailscale-CGNAT100.64.0.0/10), lockstep with the pre-publish mirror gateEach changed file is byte-for-byte identical to canonical (verified by git blob SHA). The repo's own
Secrets + content policygate re-scans this PR.🤖 Generated with Claude Code
Summary by cubic
Syncs the vendored
public-repo-guardto its canonical source for a byte-for-byte match and hardens the scan workflow.New Features
internal-ipleak rule for Tailscale CGNAT100.64.0.0/10.Dependencies
actions/checkouttov7and setpersist-credentials: falseto avoid exposing a live token to third-party binaries.Written for commit 0d27c75. Summary will update on new commits.