fix: normalise bare SHA BUILDER_REF before refs/tags/ prefix check in builder-fetch.sh

[shinagawa-web]

Summary

builder-fetch.sh rejects a bare 40-char commit SHA as BUILDER_REF with exit 2, even though the SHA-resolution path a few lines later is designed to handle exactly that case. This makes the pre-built binary download path (compile-generator: false, the default) fail for every caller that pins the reusable workflow with @<sha> — which is the pinning style the project's own security guidance recommends.

Root cause

detect-workflow-js emits the raw commit SHA when the caller pins the workflow with @<sha>. For example:

BUILDER_REF: f7dd8c54c2067bafc12ca7a55595d5ee9b75204a

The current guard at the top of builder-fetch.sh:

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

rejects the bare SHA before execution reaches the SHA-resolution loop that looks up the matching release tag.

Both v2.0.0 and v2.1.0 are affected.

Fix

Normalise a bare SHA to refs/tags/<sha> before the prefix check so the existing SHA-resolution loop can resolve it to the correct release tag:

# Normalise bare SHA (emitted by detect-workflow-js for @<sha>-pinned callers).
if [[ "$BUILDER_REF" =~ ^[a-f0-9]{40}$ ]]; then
  BUILDER_REF="${PREFIX}${BUILDER_REF}"
fi

This is a minimal, backward-compatible change. The subsequent logic is unchanged: the SHA is resolved to a release tag, the corresponding binary is downloaded, and provenance is verified.

Reproduction

Pin any of the generator_*_slsa3.yml reusable workflows with @<sha> (e.g. @f7dd8c54c2067bafc12ca7a55595d5ee9b75204a) and use the default compile-generator: false. The Generate builder step fails immediately with:

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

Test

Verified against shinagawa-web/gomarklint (public repository, v3 release workflow) where this failure was first observed and diagnosed.