Is your feature request related to a problem? Please describe.
As a user who wants to trust the binaries I download, I have no way to verify that the executables published on the GitHub releases page are actually built directly from this repository's source code. A developer with write access to the repository could theoretically upload any binary to a release — including one that was not produced from the public source code — and there is currently no mechanism for me or other users to detect this. This is a concern for anyone who wants to trust the software they are installing.
Describe the solution you'd like
I would like the project to adopt GitHub Artifact Attestations as part of its release pipeline. By adding an attestation step to the GitHub Actions workflow, each released binary would be cryptographically linked to the specific source code and workflow run that produced it. Users could then verify provenance themselves using the GitHub CLI (gh attestation verify), giving them confidence that the binary they downloaded matches the public source code.
GitHub Artifact Attestations are free, integrate natively with GitHub Actions, and use Sigstore under the hood, making this a low-cost and low-effort addition to the existing pipeline.
Describe alternatives you've considered
I considered suggesting using a code signing service, which also offers pipeline integration and links binaries to source repositories. However, these services primarily provide an embedded certificate for Windows trust purposes (e.g. avoiding SmartScreen warnings) rather than a direct cryptographic provenance guarantee. Artifact Attestations more directly address the specific concern of proving a binary was produced from the public source code. Ideally both could be used together — attestations for provenance and a signing certificate for user-facing trust signals — but attestations alone would be the more meaningful step.
Additional context
GitHub's documentation on Artifact Attestations can be found here: https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds
This is not a criticism of the project or its maintainers. It is a suggestion to add a layer of transparency that would benefit security-conscious users and strengthen trust in the project's releases.
Is your feature request related to a problem? Please describe.
As a user who wants to trust the binaries I download, I have no way to verify that the executables published on the GitHub releases page are actually built directly from this repository's source code. A developer with write access to the repository could theoretically upload any binary to a release — including one that was not produced from the public source code — and there is currently no mechanism for me or other users to detect this. This is a concern for anyone who wants to trust the software they are installing.
Describe the solution you'd like
I would like the project to adopt GitHub Artifact Attestations as part of its release pipeline. By adding an attestation step to the GitHub Actions workflow, each released binary would be cryptographically linked to the specific source code and workflow run that produced it. Users could then verify provenance themselves using the GitHub CLI (
gh attestation verify), giving them confidence that the binary they downloaded matches the public source code.GitHub Artifact Attestations are free, integrate natively with GitHub Actions, and use Sigstore under the hood, making this a low-cost and low-effort addition to the existing pipeline.
Describe alternatives you've considered
I considered suggesting using a code signing service, which also offers pipeline integration and links binaries to source repositories. However, these services primarily provide an embedded certificate for Windows trust purposes (e.g. avoiding SmartScreen warnings) rather than a direct cryptographic provenance guarantee. Artifact Attestations more directly address the specific concern of proving a binary was produced from the public source code. Ideally both could be used together — attestations for provenance and a signing certificate for user-facing trust signals — but attestations alone would be the more meaningful step.
Additional context
GitHub's documentation on Artifact Attestations can be found here: https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds
This is not a criticism of the project or its maintainers. It is a suggestion to add a layer of transparency that would benefit security-conscious users and strengthen trust in the project's releases.