ci(gitleaks): use upstream directly; drop the vendored mirror #29

Merged
ullrich merged 1 commit from ci/gitleaks-use-upstream-directly into main 2026-07-27 20:15:46 +00:00
Owner

Reverses the hosting half of #27/#28, keeps the part that mattered.

The mirror bought nothing

I justified vendoring as removing CI's GitHub dependency. It didn't. From the actual job log (run 116), the GitHub calls this one job makes:

https://github.com/zricethezav/gitleaks/releases/download/v8.24.3/gitleaks_8.24.3_linux_x64.tar.gz
https://github.com/actions/checkout

The action downloads the gitleaks binary from GitHub releases every run, and actions/checkout resolves via DEFAULT_ACTIONS_URL=github. So if GitHub is unreachable, Security Scan fails whether the action is mirrored or not. Vendoring removed one of three GitHub touchpoints in a job that still can't complete without GitHub — in exchange for a repo to keep in sync.

Integrity was never the mirror's contribution either. The pin is a commit SHA, which is content-addressed: a compromised or force-pushed upstream cannot change what e0c47f4f resolves to. Availability of the action code was the only genuine gap, and it's moot given the binary download.

My "removing CI's last GitHub dependency" claim was wrong, I corrected it on #27 — and then failed to follow the correction through to its conclusion, which is this PR.

What's kept

  • upstream v3.0.0 rather than a year-old fork point (includes chore: supply-chain hardening)
  • no merge_group patch — a GitHub merge-queue feature Forgejo doesn't have (#25)

Both were real improvements independent of where the action is hosted.

Verified

  • upstream e0c47f4f anonymously reachable → 200
  • GITLEAKS_ENABLE_UPLOAD_ARTIFACT is an upstream feature, not a local patch, so the SARIF-upload workaround still applies. Without it the action's @actions/artifact v2 upload throws GHESNotSupportedError against Forgejo and fails the job on a clean scan — i.e. it would look like gitleaks found something.
  • pinned by SHA, not by tag: v3 is a moving pointer and would defeat the integrity argument above.

CI / Security Scan on this PR is the test, as before.

The now-unreferenced mirror

git.ullrich.is/trails-cool/gitleaks-action is no longer referenced by anything. I've left it in place rather than deleting it — it costs ~1.5MB and would be the starting point if we ever do the full GitHub-free CI work (host the binary, mirror actions/*). Happy to delete it instead; it's a repo on your instance and deletion isn't mine to assume.

Reverses the hosting half of #27/#28, keeps the part that mattered. ## The mirror bought nothing I justified vendoring as removing CI's GitHub dependency. It didn't. From the actual job log (run 116), the GitHub calls this one job makes: ``` https://github.com/zricethezav/gitleaks/releases/download/v8.24.3/gitleaks_8.24.3_linux_x64.tar.gz https://github.com/actions/checkout ``` The action downloads the **gitleaks binary** from GitHub releases every run, and `actions/checkout` resolves via `DEFAULT_ACTIONS_URL=github`. So if GitHub is unreachable, `Security Scan` fails whether the action is mirrored or not. Vendoring removed **one of three** GitHub touchpoints in a job that still can't complete without GitHub — in exchange for a repo to keep in sync. **Integrity was never the mirror's contribution either.** The pin is a commit SHA, which is content-addressed: a compromised or force-pushed upstream cannot change what `e0c47f4f` resolves to. Availability of the action code was the only genuine gap, and it's moot given the binary download. My "removing CI's last GitHub dependency" claim was wrong, I corrected it on #27 — and then failed to follow the correction through to its conclusion, which is this PR. ## What's kept - **upstream v3.0.0** rather than a year-old fork point (includes `chore: supply-chain hardening`) - **no `merge_group` patch** — a GitHub merge-queue feature Forgejo doesn't have (#25) Both were real improvements independent of where the action is hosted. ## Verified - upstream `e0c47f4f` anonymously reachable → 200 - `GITLEAKS_ENABLE_UPLOAD_ARTIFACT` is an **upstream** feature, not a local patch, so the SARIF-upload workaround still applies. Without it the action's `@actions/artifact` v2 upload throws `GHESNotSupportedError` against Forgejo and fails the job on a *clean* scan — i.e. it would look like gitleaks found something. - pinned by SHA, not by tag: `v3` is a moving pointer and would defeat the integrity argument above. `CI / Security Scan` on this PR is the test, as before. ## The now-unreferenced mirror `git.ullrich.is/trails-cool/gitleaks-action` is no longer referenced by anything. I've **left it in place rather than deleting it** — it costs ~1.5MB and would be the starting point if we ever do the full GitHub-free CI work (host the binary, mirror `actions/*`). Happy to delete it instead; it's a repo on your instance and deletion isn't mine to assume.
ci(gitleaks): use upstream directly; drop the vendored mirror
All checks were successful
CI / Dockerfile Package Check (pull_request) Successful in 24s
CI / Security Scan (pull_request) Successful in 44s
CI / Checks (pull_request) Successful in 3m15s
CI / Visual Tests (pull_request) Successful in 3m4s
CI / Journal Image Smoke Test (pull_request) Successful in 4m47s
CI / E2E Tests (pull_request) Successful in 7m20s
f2f04f05b4
Reverses the hosting half of #27/#28 while keeping the part that mattered:
upstream v3.0.0, no local patch.

The mirror was justified as removing CI's GitHub dependency. It did not.
The same step still downloads the gitleaks binary from
github.com/zricethezav/gitleaks/releases on every run, and
`actions/checkout` resolves via DEFAULT_ACTIONS_URL=github — both visible in
the job log for run 116. So if GitHub is unreachable, Security Scan fails
whether or not the action is mirrored. Vendoring removed one of three GitHub
touchpoints in a job that still cannot complete without GitHub, in exchange
for a repo to keep in sync.

Integrity was never the mirror's contribution either: the pin is a commit
SHA, which is content-addressed, so a compromised or rewritten upstream
cannot change what e0c47f4f resolves to. Availability of the action code was
the only real gap, and it is moot given the binary download.

What is kept from #28: v3.0.0 instead of a year-old fork point, and no
`merge_group` patch (a GitHub merge-queue feature Forgejo does not have,
issue #25). Those were genuine improvements independent of hosting.

Verified: upstream e0c47f4f is anonymously reachable (200), and
GITLEAKS_ENABLE_UPLOAD_ARTIFACT is an upstream feature rather than a local
patch, so the SARIF-upload workaround still applies — without it the
action's @actions/artifact v2 upload throws GHESNotSupportedError against
Forgejo and fails the job on a clean scan.

The vendored repo at git.ullrich.is/trails-cool/gitleaks-action is now
unreferenced. Left in place for now rather than deleted; it costs ~1.5MB and
would be the starting point if we ever do the full GitHub-free CI work.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X8hNxgYp777FRqYtVmQNaU
ullrich deleted branch ci/gitleaks-use-upstream-directly 2026-07-27 20:15:46 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
trails-cool/trails!29
No description provided.