fix(ci): do not persist the job token in .git/config in the public-repo guard
Why
actions/checkout without persist-credentials: false writes the job's GITHUB_TOKEN into
.git/config, where any later step — or anything those steps execute — can read it. This is the
security gate that DOWNLOADS AND EXECUTES the gitleaks binary, and the workflow's own comment
already reasons about tampered downloads ("so a tampered or MITM'd download can never execute
inside the security gate"), so the threat model is written down and only the credential half of
the mitigation is missing. Found by zizmor as warning[artipacked]: credential persistence through GitHub Actions artifacts.
Safety
Verified this job only: checks out, installs gitleaks (pinned + checksum), runs
gitleaks detect --no-git, installs ripgrep, runs content-policy.sh. permissions: contents: read. Nothing pushes, calls gh, or reads GITHUB_TOKEN/GH_TOKEN, so the token was never needed
in .git/config in the first place.
Refs wave-av/claude-workstation#1870.
[!NOTE]
Low Risk
Single workflow hardening with no change to scan logic or permissions; aligns with other workflows that already disable credential persistence.
Overview
Sets persist-credentials: false on the actions/checkout step in the public-repo-guard workflow so the job’s GITHUB_TOKEN is not written into .git/config.
That matters because later steps download and run the pinned gitleaks binary and execute content-policy.sh; anything in those paths could otherwise read credentials from git config. The workflow already treats tampered downloads as part of the threat model; this closes the credential-persistence gap flagged by zizmor (artipacked). The job only needs contents: read and does not push or use gh, so omitting persisted credentials does not change intended behavior.
Reviewed by Cursor Bugbot for commit e140fba9845e0ea572eeb64da26171c9e5ceb44c. Configure here.