builder-fetch.sh exits 2 when BUILDER_REF is a bare SHA (SHA-pinned callers always fail with compile-generator: false)

[shinagawa-web]

Summary

When a caller pins the reusable workflow with @<sha> (the pinning style the project's own security documentation recommends), detect-workflow-js emits the raw 40-char commit SHA as BUILDER_REF. builder-fetch.sh then immediately fails:

BUILDER_REF: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a
Invalid ref: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a. Expected ref of the form refs/tags/vX.Y.Z

This makes the default compile-generator: false path broken for all SHA-pinned callers.

Affected versions

Both v2.0.0 and v2.1.0 (and main as of 2026-05-05).

Root cause

builder-fetch.sh has a prefix guard at the top:

PREFIX="refs/tags/"
if [[ "$BUILDER_REF" != "$PREFIX"* ]]; then
  echo "Invalid ref: $BUILDER_REF. Expected ref of the form refs/tags/vX.Y.Z"
  exit 2
fi
builder_tag="${BUILDER_REF#"$PREFIX"}"

if [[ "$builder_tag" == "$(echo -n "$builder_tag" | grep -P '^[a-f\d]{40}$')" ]]; then
  # SHA-resolution loop — resolves commit hash to a release tag
  ...

A bare SHA fails the prefix check and exits before reaching the SHA-resolution loop that was clearly written to handle this exact case.

Impact

Any project that follows the recommended @<sha> pinning pattern and uses compile-generator: false (the default) will see Generate builder fail silently (the step has continue-on-error: true) and the entire provenance generation skipped. The failure was observed and diagnosed in shinagawa-web/gomarklint during a v3.0.x release.

Proposed fix

Normalise a bare SHA to refs/tags/<sha> before the prefix check so the existing resolution loop is reached:

if [[ "$BUILDER_REF" =~ ^[a-f0-9]{40}$ ]]; then
  BUILDER_REF="${PREFIX}${BUILDER_REF}"
fi

A PR with this fix is open at #4502.