ci: attest build provenance for the release binaries

[kobihikri]

Hi, and thanks for act.

The release workflow builds and publishes the binaries with GoReleaser, but nothing attests them, so a downloaded act_Linux_x86_64.tar.gz carries no evidence of where it came from. Anyone who has the release assets has to take on trust that they were produced by this workflow from this tag.

That matters a little more than usual for act specifically: it is a developer tool people install to run CI locally, often via a curl | bash style install script or a package manager that just fetches the GitHub release asset. It tends to end up on machines that also hold repository credentials.

This PR adds GitHub's build attestation after the GoReleaser step:

permissions:
  contents: write
  actions: write
  id-token: write      # for build provenance signing
  attestations: write  # to record the attestation
...
      - name: Attest build provenance
        uses: actions/attest-build-provenance@977bb373ede98d70efdf65b84cb5f73e068dcc2a # v3.0.0
        with:
          subject-path: |
            dist/*.tar.gz
            dist/*.zip
            dist/checksums.txt

The subject paths follow your .goreleaser.yml — the default archive format plus the zip override for Windows, and the checksums.txt from the checksum block. After a release, anyone can verify an asset with:

gh attestation verify act_Linux_x86_64.tar.gz --repo nektos/act

which reports the workflow, the commit and the run that produced it. Nothing else changes: GoReleaser runs exactly as before, and the Winget, Chocolatey and gh-extension steps that follow are untouched.

Two honest notes:

• The two added permissions are additive; the existing contents: write and actions: write are unchanged, so the rest of the job keeps the access it has today.
• This signs what GoReleaser has already written to dist/. If you would rather attest only the archives and not checksums.txt, dropping that line is harmless — the checksums file is covered indirectly anyway.

I have not claimed any SLSA level for this; the attestation is what it is, and the level depends on how you characterise the whole build.

Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow and your GoReleaser config myself.