Add SLSA build provenance (or SHA256SUMS) for committed dist/bin/ launcher binaries

[potiuk]

Hi matlab-actions team,

Starting with v3.1.0 / v3.1.1 the release pipeline commits the MATLAB launcher binaries directly into the action tree:

dist/bin/glnxa64/run-matlab-command
dist/bin/maca64/run-matlab-command
dist/bin/maci64/run-matlab-command
dist/bin/win64/run-matlab-command.exe

This is a real improvement over fetching them via common-utils at install time — consumers who pin a SHA now get exactly the bytes you shipped at release time, not whatever a CDN happens to serve later.

It does, however, leave one gap on the downstream-review side: there's no way to tie those bytes back to the workflow run that produced them. The launcher (src/index.ts → dist/index.js) rebuilds cleanly from source, but the four native binaries are opaque to any rebuild check.

We're running into this on the Apache Software Foundation side, where apache/infrastructure-actions allowlists every action SHA used by ASF projects. Our automated check (verify-action-build) classifies v3.1.1 as "unverified pre-compiled binaries" because neither of its two verification paths is available:

1. gh attestation verify --owner matlab-actions <binary> — no SLSA attestation found.
2. Release asset SHA256SUMS — no assets are attached to any release.

The downstream PR is apache/infrastructure-actions#846; we'd like to land v3.1.1, but the policy is to hold in-tree binaries without provenance.

Either of these would close the gap:

(a) Add actions/attest-build-provenance to .github/workflows/publish.yml so each binary gets a SLSA attestation. The runs-on/action project did this in a one-line PR (runs-on/action#37) and the result was that gh attestation verify --owner runs-on <binary> started succeeding for every subsequent release. This is the strongest signal and ideal because it ties each artifact to the exact workflow run.

(b) Or ship a SHA256SUMS file as a release asset listing the four dist/bin/* binaries. A simple sha256sum dist/bin/*/run-matlab-command* > SHA256SUMS + gh release upload step in publish.yml works. Weaker than (a) (the checksum file itself isn't signed yet) but a strong cryptographic chain from release to the bytes that ship.

Happy to send a PR with the workflow change if it would help — let me know which path you'd prefer.

Thanks!

[davidbuzinski]

This is a good suggestion. I'll take at a look at the options today and keep you updated here.

Thanks!
David B

[davidbuzinski]

Hi @potiuk ,

We've opted to use your first suggestion using GitHub's attest action. We created a v3.1.2 release using attestations. Now if I checkout the v3.1.2 tag, I can run gh attestation verify to verify the binaries:

$ gh attestation verify --owner matlab-actions --predicate-type https://slsa.dev/provenance/v1 dist/bin/glnxa64/run-matlab-command
Loaded digest sha256:9450d17e364086ae75dce1fb2e324c969667d862109dfcdfe7fe4b9333f90afd for file://dist/bin/glnxa64/run-matlab-command
Loaded 3 attestations from GitHub API

The following policy criteria will be enforced:
- Predicate type must match:................ https://slsa.dev/provenance/v1
- Source Repository Owner URI must match:... https://github.com/matlab-actions
- Subject Alternative Name must match regex: (?i)^https://github.com/matlab-actions/
- OIDC Issuer must match:................... https://token.actions.githubusercontent.com

✓ Verification succeeded!

The following 3 attestations matched the policy criteria

- Attestation #1
  - Build repo:..... matlab-actions/run-tests
  - Build workflow:. .github/workflows/publish.yml@refs/tags/v3.1.2
  - Signer repo:.... matlab-actions/run-tests
  - Signer workflow: .github/workflows/publish.yml@refs/tags/v3.1.2

- Attestation #2
  - Build repo:..... matlab-actions/run-command
  - Build workflow:. .github/workflows/release.yml@refs/tags/v3.1.2
  - Signer repo:.... matlab-actions/run-command
  - Signer workflow: .github/workflows/release.yml@refs/tags/v3.1.2

- Attestation #3
  - Build repo:..... matlab-actions/run-build
  - Build workflow:. .github/workflows/publish.yml@refs/tags/v3.1.2
  - Signer repo:.... matlab-actions/run-build
  - Signer workflow: .github/workflows/publish.yml@refs/tags/v3.1.2

It is interesting to note that there will be multiple attestations tied to each binary because the binaries are not unique and aren't built during the workflows; they are downloaded from a CDN for the release as you noted. Please let us know if this works for your use-case, and feel free to close the issue if it does.

Thank you!
David B

[potiuk]

Thanks @davidbuzinski, that was a fast turnaround! Just verified end-to-end on the ASF side — gh attestation verify --owner matlab-actions --predicate-type https://slsa.dev/provenance/v1 dist/bin/*/run-matlab-command* against the v3.1.2 commit (4c375221b861) passes for every launcher, and our verify-action-build pipeline now picks up the attestations automatically (in-tree binary check ✓). Really appreciate the engagement.