Security: Release artifact provenance for c4z (and HACS) — SLSA attestation + checksums

[caidurbin]

What to build

Give the non-PyPI release artifacts the provenance the PyPI lane gets from PEP 740. There's no index-side attestation story for .c4z or the HACS GitHub release, so attach SLSA build provenance (actions/attest-build-provenance) and publish a checksum for the .c4z artifact, letting consumers verify it was built by this repo's workflow. Evaluate doing the same for the HACS release.

Acceptance criteria

• .c4z release publishes a SLSA build-provenance attestation and a checksum
• Verification steps documented for consumers
• Decision recorded on whether/how to apply the same to the HACS release

Blocked by

None - can start immediately

[caidurbin]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Attach SLSA build-provenance attestation + a published checksum to the .c4z release artifact, and record a decision on doing the same for the HACS release.

Current behavior:
The PyPI lane gets provenance for free via PEP 740 attestations, but the .c4z release (built deterministically by the c4z build tooling and published via the GitHub-release action) ships with no attestation and no checksum. A consumer downloading a .c4z from a GitHub release cannot verify it was built by this repo's workflow. The HACS GitHub release is in the same position.

Desired behavior:
The .c4z release publishes a SLSA build-provenance attestation (via actions/attest-build-provenance) and a checksum, so consumers can verify origin and integrity. This repo is public, so attestation needs only workflow-level permissions (id-token: write, attestations: write, contents: write) — no GitHub Advanced Security purchase or admin toggle. Consumer-side verification steps (e.g. gh attestation verify) are documented. A decision is recorded on whether to extend the same provenance to the HACS release.

Key interfaces:

• The .c4z release workflow — add an attestation step over the built artifact and a step that emits and attaches a checksum file to the release. Ensure the publishing job carries the required permissions.
• Consumer verification docs — a short, discoverable section (README or release notes) showing how to verify the attestation and checksum.
• The HACS release workflow — evaluate applying the same; capture the decision (an ADR, or a note in the workflow/security docs).

Acceptance criteria:

• .c4z release publishes a SLSA build-provenance attestation and a checksum
• Verification steps are documented for consumers
• A decision is recorded on whether/how to apply the same to the HACS release
• The release workflow still builds/publishes successfully with the added permissions and steps

Out of scope:

• The PyPI lane (already covered by PEP 740).
• Signing infrastructure beyond what actions/attest-build-provenance provides (no separate cosign keypair management unless the HACS decision requires it).