chore(guard): sync vendored public-repo-guard to canonical - #24
chore(guard): sync vendored public-repo-guard to canonical#24wave-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 2dff537. This is a minor CI/CD security improvement (bumping actions/checkout and disabling credential persistence), but the workflow file is owned by wave-av/core-team and the author (release bot) is not a designated owner. The code owners should review this sync. You can customize Macroscope's approvability policy. Learn more. |
| - 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.
🔍 Checkout action pin now inconsistent across workflows
This workflow now pins actions/checkout at v7.0.0 while .github/workflows/python-lint.yml:23 pins v6.0.3 and .github/workflows/_checks.yml:23,54,114 still pin v4.3.1 — none of which set persist-credentials: false. If the intent is the zizmor artipacked hardening, the other workflows remain unhardened and the version drift makes future SHA bumps easy to miss.
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.
🔍 Verify the pinned SHA actually corresponds to v7.0.0
The commit SHA is the only thing enforced at run time; the # v7.0.0 comment is unverifiable from the repo. Worth confirming 9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 is the tagged v7.0.0 commit of actions/checkout, since a mismatched pin in the security-gate workflow would silently run a different action revision. The subsequent steps (download/extract gitleaks, gitleaks detect --no-git, ripgrep policy script) need no Git credentials, so persist-credentials: false is safe here.
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
Note
Update
public-repo-guardworkflow to useactions/checkoutv7 without persisted credentialsSyncs public-repo-guard.yml to the canonical version. Upgrades
actions/checkoutfrom v5.0.1 to v7.0.0 and setspersist-credentials: falseso theGITHUB_TOKENis no longer stored in the repository's Git config after checkout.Macroscope summarized 2dff537.
Summary by cubic
Synced the vendored
public-repo-guardto the canonicalwave-foundation/scaffolder/public-repo-guardand hardened the workflow. Adds the internal-IP leak rule for Tailscale CGNAT (100.64.0.0/10), and updates toactions/checkout@v7withpersist-credentials: falseto reduce credential exposure duringgitleaksscans.Written for commit 2dff537. Summary will update on new commits.