Add release workflow

[AdamKorcz]

Summary

This adds a GitHub workflow for releasing the sigstore-go source code and provenance attestation.

For current status on this PR, see #280 (comment)

---

Old intro below kept for tracking. See #280 (comment) for current status

Sample run: https://github.com/AdamKorcz/sigstore-go/actions/runs/10516249552

I have made a few decisions that need consideration:

1. So far, sigstore-go's releases have been source code only. With this workflow, sigstore-go will release binaries with attestation for these binaries. This might not be the way that users consume sigstore-go at the moment, and we should consider if we should add attestations for the source code instead.
2. The workflow builds and releases binaries for linux, macos and windows. Should sigstore-go do that?
3. Should the release workflow run make test or should that be a separate workflow?
4. The names of the final binaries are "sigstore-go-${{ matrix.os }} with ".exe" for windows.
5. There is no attestation for windows binaries because it is not supported.
6. For easier testing, the triggers are now either dispatch or push.

The windows runner is giving me some problems which is why I am hardcoding the binary name:

      with:
          name: 'sigstore-go-windows-latest.exe'
          path: 'sigstore-go-windows-latest.exe'

It could be refactored to look nicer.

Release Note

Documentation

[AdamKorcz]

@haydentherapper Could you have a look?

[haydentherapper]

So far, sigstore-go's releases have been source code only. With this workflow, sigstore-go will release binaries with attestation for these binaries. This might not be the way that users consume sigstore-go at the moment, and we should consider if we should add attestations for the source code instead.

This was intentional to only release source code archives. We want to discourage users using the sigstore-go CLIs - they are meant as examples for signing and verification.

I'd say we only need a provenance attestation on how the source archive was built.

[kommendorkapten]

I would also not recommend releasing any binaries by the reason @haydentherapper mentions.

[AdamKorcz]

Current status with c3d757f

Sample run: https://github.com/AdamKorcz/test-releasing/actions/runs/10564714125

I have adjusted the workflow so that it generates verifiable provenance for the compressed sigstore-go source archives.

The interoperability between the compressed source archives and https://github.com/actions/attest-build-provenance is not great (although there are many good things to say about https://github.com/actions/attest-build-provenance), so I've had to do some workarounds. The following areas lack support to make generating provenance for source archives simpler:

1. AFAICT, we don't have access to the source archives before a release has been issued. I have mitigated this by first issuing a releasing, then download the source archives and generate provenance for them.
2. There are multiple ways you can download the source archives, and they all have different formats. We need to generate provenance for all of them. The main difference is what the directory is called after you compress it. Decompressed archives will be called sigstore-sigstore-go-latest-commit (7 first digits). Another will be called sigstore-go-0.7.0 (without "v"), and another will be called sigstore-go-v0.7.0 (with "v"). GitHub needs an attestation for each compressed archive, because the gh binary will look up attestation based on the compressed archives checksum.
3. GitHub generates the compressed source archives by way of git archive. I have tried to reproduce the command that generate the archives, but I not been successful.

Verifying provenance

With the current state of the workflow, users can download the sigstore-go source archives by any of the following ways and verify them. These are tested out on my own repo, so I am adding reproducible steps that succesfully verify. With the workflow in sigstore-go's own repo, the links would be https://github.com/sigstore/sigstore-go instead of https://github.com/AdamKorcz/test-releasing.

1. First, generate a token with content:read permissions for https://github.com/AdamKorcz/test-releasing.
2. Next setup the gh CLI tool locally.
3. Then, do one of the following:

Method 1: curl (zipball)

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/AdamKorcz/test-releasing/zipball/v0.2.6 > artifact.zip

2. gh attestation verify artifact.zip --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:22d5242aa2107d16920d2d3aeb9b4fd7b0d8992b0ebb604b21b190de1447c99e for file://artifact.zip
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:22d5242aa2107d16920d2d3aeb9b4fd7b0d8992b0ebb604b21b190de1447c99e was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

Method 2: curl (tarball)

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/AdamKorcz/test-releasing/tarball/v0.2.6 > artifact.tar.gz

2. gh attestation verify artifact.tar.gz --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:6a2b5cf8671de291aad4fab2020341044905efa2a9e9f352ab82be1e7b394b9d for file://artifact.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:6a2b5cf8671de291aad4fab2020341044905efa2a9e9f352ab82be1e7b394b9d was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

Method 3: wget archive/tags/REF (zipball)

1. wget https://github.com/AdamKorcz/test-releasing/archive/tags/v0.2.6.zip
2. gh attestation verify v0.2.6.zip --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:dee47b879d1493dce252032f2793af459b43ba49fc966baf6843cdc8192bbb54 for file://v0.2.6.zip
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:dee47b879d1493dce252032f2793af459b43ba49fc966baf6843cdc8192bbb54 was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

Method 4: wget archive/tags/REF (tarball)

1. wget https://github.com/AdamKorcz/test-releasing/archive/tags/v0.2.6.tar.gz
2. gh attestation verify v0.2.6.tar.gz --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:4af7194a96f05a08189a5c0fc824bfcfacc8cbd0e5f9f37787727d513a3a91b7 for file://v0.2.6.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:4af7194a96f05a08189a5c0fc824bfcfacc8cbd0e5f9f37787727d513a3a91b7 was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

Method 5: wget archive/refs/tags/REF (zipball)

(same as Source code (tar.gz) link from release page

1. wget https://github.com/AdamKorcz/test-releasing/archive/refs/tags/v0.2.6.zip
2. gh attestation verify v0.2.6.zip --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:cfd47adfae74fbdeeebf1fee424317aef540e65875017b52296a473235fca973 for file://v0.2.6.zip
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:cfd47adfae74fbdeeebf1fee424317aef540e65875017b52296a473235fca973 was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

Method 6: wget archive/refs/tags/REF (tarball)

(same as Source code (zip) link from release page

1. wget https://github.com/AdamKorcz/test-releasing/archive/refs/tags/v0.2.6.tar.gz
2. gh attestation verify v0.2.6.tar.gz --repo=AdamKorcz/test-releasing

Output:

Loaded digest sha256:4af7194a96f05a08189a5c0fc824bfcfacc8cbd0e5f9f37787727d513a3a91b7 for file://v0.2.6.tar.gz
Loaded 1 attestation from GitHub API
✓ Verification succeeded!

sha256:4af7194a96f05a08189a5c0fc824bfcfacc8cbd0e5f9f37787727d513a3a91b7 was attested by:
REPO                      PREDICATE_TYPE                  WORKFLOW                                      
AdamKorcz/test-releasing  https://slsa.dev/provenance/v1  .github/workflows/release.yml@refs/tags/v0.2.6

TODO:

1. This should be scrutinized in terms of hardening. The workflow processes files from compressed archives that can be untrusted although it is highly unlikely. This does not necessarily have to be done in this PR.
2. We could consider a delete tag and release-fallback step, in case any of the steps fail. Currently, the workflow can issue a release without provenance, in case any of the provenance-related steps fail.
3. Consider the UX. With this workflow, you push a tag to cut a release. This is a bit different from the current workflow - I believe currently you push a tag and manually click the "New Release" button, but I think with TODO.2, this should work just as well.

[AdamKorcz]

@haydentherapper @kommendorkapten I am keeping this in draft, but could you consider c3d757f and #280 (comment)