Add SLSA Go releaser workflow

[distressedmykah]

This workflow compiles a Go project using a SLSA3 compliant builder and generates a provenance file.

Resolves #ISSUE_NUMBER

---

Before the change?

After the change?

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[ViacheslavKudinov]

Hi @distressedmykah
I was thinking the original idea of the "Salsa" Go builder to replace Goreleaser to perform the whole build ? Maybe im wrong.
I read that it can be used together if it makes sense. Not sure, its new area for me.

It seems GitHub introduced some time ago own attestation (provenance) solution https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/increase-security-rating.
Maybe is better to use GitHub "native" solution https://github.com/actions/attest-build-provenance ?
What do you think ?

[ViacheslavKudinov]

I did some tests on my fork with GitHub attestation.

The release workflow can be modified like this one https://github.com/vk-or/terraform-provider-github/blob/main/.github/workflows/release.yml#L50-L52
Provenance for test release to prove it works - https://github.com/vk-or/terraform-provider-github/attestations/12524829

Maybe @nickfloyd could share what is preferable way for this repo.

[ViacheslavKudinov]

I do not think this workflow (from PR) will work as it is not prevenance generator but whole build to replace Goreleaser.
It could be the idea was to just generate provenance, then it is something what is described there https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/generic/README.md#provenance-for-goreleaser
I couldn't yet make it working for me, but maybe need more time.
At least actions/attest-build-provenance works well and easy to get it.
Will try more to see what i can get with slsa-framework/slsa-github-generator

[ViacheslavKudinov]

Finally I could get multiple.intoto.jsonl as result of the run of slsa-generation for Goreleaser (final workflow on the POC repo).
According to this repo it is what is expected to get some intoto.jsonl file.
But to verify i need to install extra CLI slsa-verifier and follow something like

• get files from repo

gh release download -R vk-sts/terraform-provider-github -p "*.intoto.jsonl"
gh release download -R vk-sts/terraform-provider-github -p "*.zip"

• verify integrity

 slsa-verifier verify-artifact \
                    --provenance-path multiple.intoto.jsonl \
                    --source-uri github.com/vk-sts/terraform-provider-github  \
                    --source-tag v0.0.4 \
                     terraform-provider-github_0.0.4_freebsd_amd64.zip

to be honest i would prefer GitHub cli and GitHub attestation to prove integrity (more easy to set up Actions and to get verification as many of us have GH CLI installed), instead of suggested SLSA way.
But it is just my opinion, other people could prefer solution like from this PR, based on SLSA framework implementation.

[nickfloyd]

@ViacheslavKudinov Thanks for thinking through this. My preference would be to use the GitHub native solution actions/attest-build-provenance and integrate with the existing GoReleaser workflow rather than replacing it.

Something like this in the release.yaml file with id-token and attestations write permissions:

  - name: Generate build attestations
        uses: actions/attest-build-provenance@somever
        with:
          subject-path: 'dist/*.zip'

If we were to make something like this a priority I'd like the change to be a small iteration and low impact to our ci as possible.

[ViacheslavKudinov]

@ViacheslavKudinov Thanks for thinking through this. My preference would be to use the GitHub native solution actions/attest-build-provenance and integrate with the existing GoReleaser workflow rather than replacing it.

Something like this in the release.yaml file with id-token and attestations write permissions:

  - name: Generate build attestations
        uses: actions/attest-build-provenance@somever
        with:
          subject-path: 'dist/*.zip'

If we were to make something like this a priority I'd like the change to be a small iteration and low impact to our ci as possible.

@nickfloyd you are welcome.
it is exactly how i did on the POC repo https://github.com/vk-or/terraform-provider-github/blob/main/.github/workflows/release.yml#L50-L52, just a little bit more "precise" subject-path.
Result is visible there https://github.com/vk-or/terraform-provider-github/attestations/12524829.

I will create a PR to address it with actions/attest-build-provenance

Validation could be done by running (attestation was created for v0.0.4)

gh release download v0.0.4 -R vk-or/terraform-provider-github -p "*.zip"
gh attestation verify --owner vk-or terraform-provider-github_0.0.4_freebsd_amd64.zip
# or
# gh attestation verify --owner vk-or --signer-repo vk-or/terraform-provider-github terraform-provider-github_0.0.4_freebsd_amd64.zip 

[ViacheslavKudinov]

Added another PR #2846

[stevehipwell]

The current build process should already be compliant.