ci: SLSA provenance generation broken in v2.1.0 (privacy-check false positive)

[cjimti]

Summary

The provenance job in .github/workflows/release.yml fails at the provenance / final step even though the repo is public. First observed on the v1.25.14 release (workflow run). No user-facing impact — release assets, the homebrew tap, and the MCP Registry publish all succeed. Only the SLSA attestation artifact is missing from the release.

Why it surfaced now

The SLSA reusable workflow was bumped from v2.0.0 → v2.1.0 in commit af9f298 (dependabot). Every kubefwd release between v1.25.1 and v1.25.13 had the release job fail first (unrelated MCP Registry bug, fixed in #470), so the provenance job was always skipped and this regression stayed hidden. v1.25.14 is the first release to actually run provenance since the v2.1.0 bump, and it fails.

Root cause

SLSA v2.1.0's privacy-check action is flagging this repo as private and halting:

##[group]Run ./__BUILDER_CHECKOUT_DIR__/.github/actions/privacy-check
with:
  error_message: Repository is private. The workflow has halted in order to
    keep the repository name from being exposed in the public transparency
    log. Set 'private-repository' to override.
  override: false

The API response in the same log correctly shows "private": false, and gh repo view txn2/kubefwd --json isPrivate,visibility returns {"isPrivate":false,"visibility":"PUBLIC"}. So the misdetection is internal to SLSA v2.1.0's privacy-check logic.

Downstream failures cascade from this:

• Process completed with exit code 2 (privacy-check)
• Process completed with exit code 127 (generator binary never built)
• Input required and not supplied: path (uploader has no artifact to upload)
• Process completed with exit code 27 (final step sentinel)

Related upstream: slsa-framework/slsa-github-generator#4493, #1428.

Impact

• ❌ SLSA provenance attestation not attached to release
• ✅ Release assets, homebrew formula, MCP Registry, docker images — all unaffected
• ✅ Cosign sigstore bundles for archives still present (that's a separate signing path)

For almost all users this is invisible. Security-conscious downstream consumers that rely on SLSA attestations for supply-chain verification are affected.

Options

1. Pin back to v2.0.0 (known working, used for v1.25.0 Dec 2025). Add a dependabot ignore for this action until upstream ships a fix.

   uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.0.0

2. Add private-repository: true as a workaround. Semantically wrong for a public repo, but bypasses the broken detection. Spec implications for SLSA level unclear.
3. Wait for an upstream fix. v2.1.0 is currently the latest; no v2.1.1 or v2.2.0 yet. Provenance remains missing until then.
4. Drop the provenance job entirely. We already sign archives with cosign. SLSA is stricter supply-chain provenance; dropping it is a downgrade but removes the dead CI step.

Recommendation

Start with (1) — pin to v2.0.0 and add a dependabot ignore. Low-risk, restores working provenance, keeps the door open to re-enable newer SLSA when the upstream bug is fixed. I can send that PR if you want it.

Reproduction

• Failing run: https://github.com/txn2/kubefwd/actions/runs/24767534962
• Failed job: provenance / final (id 72467520499)
• Generator log with the privacy-check error: job id 72467447454