Chore: Migrate from attest-build-provenance to attest

[ModeSevenIndustrialSolutions]

Finding

actions/attest-build-provenance has become a no-op wrapper. From its v4.2.2 release notes:

As of version 4, actions/attest-build-provenance is simply a wrapper on top of actions/attest.

Existing applications may continue to use the attest-build-provenance action, but new implementations should use actions/attest instead.

Reading its action.yml confirms this literally: the composite forwards every input verbatim to actions/attest@508db95 # v4.2.1 and contains no logic of its own. When no predicate-type/predicate is supplied, actions/attest emits SLSA build provenance by default, so there is nothing to hand-roll on migration.

Why this repository is the priority case

Unlike the five sibling issues, the reference here is commented out — .github/workflows/build-test-release.yaml L410-420:

      # TEMPLATE: When your build action does NOT handle attestations
      # itself, uncomment this step to generate SLSA build provenance
      # for real artefacts (verifiable with `gh attestation verify`).
      # It ships commented out because attesting the trivial placeholder
      # artefact provides no value:
      #   - name: 'Attest build provenance'
      #     if: inputs.attestations
      #     uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32  # v4.1.0
      #     with:
      #       subject-path: 'dist/*'

That makes it more important to update rather than less. This is the snippet every new repository is instructed to uncomment, so leaving it seeds the superseded pattern into projects that do not exist yet — each of which then needs its own migration later. Every other issue in this set fixes one usage; this one prevents future ones.

The pin is also behind: a2bbfa2 (v4.1.0) against the portfolio's usual 4d10147 (v4.2.2). The migration supersedes the bump.

Suggested change

      # TEMPLATE: When your build action does NOT handle attestations
      # itself, uncomment this step to generate SLSA build provenance
      # for real artefacts (verifiable with `gh attestation verify`).
      # It ships commented out because attesting the trivial placeholder
      # artefact provides no value:
      #   - name: 'Attest build provenance'
      #     if: inputs.attestations
      #     uses: actions/attest@<pinned-sha>  # v4.2.1
      #     with:
      #       subject-path: 'dist/*'

actions/attest emits SLSA build provenance by default with only subject-path supplied, so the snippet stays exactly this short. The gh attestation verify guidance in the surrounding comment remains accurate.

Priority

Higher than the sibling issues for the reason above, though still not urgent — GitHub is explicit that existing applications may continue using the wrapper, and nothing carries a removal date.

References

• actions/attest
• actions/attest-build-provenance v4.2.2 release notes
• GitHub docs: Use artifact attestations
• GitHub docs: Using artifact attestations to establish provenance for builds
• Original finding and portfolio-wide survey: Feat: Add attestation and Sigstore signing to merge node-workflows#53 (comment)

[ModeSevenIndustrialSolutions]

Correction to the wording above (no change to the work here)

I described actions/attest-build-provenance as a "pure passthrough" that "adds no logic of its own". That is inaccurate: the v4 wrapper also sets NODE_OPTIONS: "--max-http-header-size=32768" on its actions/attest step, added by actions/attest-build-provenance#687 because node's default 16KB header limit overflows against some OCI registries when pushing attestations to a registry.

The commented-out template snippet here does not use push-to-registry, so the migration remains a like-for-like swap of the uses: line and pin.

There is, however, a template-specific angle worth weighing. Since this snippet is what new repositories copy, and some of those will go on to push container images, consider whether the template comment should mention the NODE_OPTIONS requirement — otherwise a project that later adds push-to-registry inherits a subtly under-configured attestation step with nothing to warn them. A one-line note alongside the existing "uncomment this step" guidance would cover it.

Two of the six repositories carrying this migration hit this for real — lfreleng-actions/docker-workflows#41 and lfreleng-actions/sigul-sign-docker#192 — and both issues are updated to require carrying the setting across.

"Thin wrapper" is the accurate description, not "pure passthrough". Credit to Copilot for catching this on lfreleng-actions/node-workflows#57.