d0ugal / d0ugal/graith

[CI-FU-07] ci: release-integrity hardening — attestation and Harden-Runner

Open
#706 1 comment 0 reactions 0 assignees View on GitHub
enhancement size: S testing
Dominant language
Go
Stars
2
Forks
0
Avg merge
5h 49m
Merged PRs (30d)
189

Description

Follow-up to #697 for release-integrity hardening.

## Current status (reassessed 2026-08-07)

- [x] Stable release provenance landed in #1581 and remains present on current `origin/main`: `attest-stable` finalizes and attests the stable `dist/*` set with `id-token: write` and `attestations: write`, while `publish-stable` verifies each artifact against the repo, signer workflow, source digest, and tag ref before publication.
- [x] Dev-release Linux provenance remains present: `attest-linux` attests the Linux amd64/arm64 archives, and `publish-dev` verifies both Linux archives before publishing.
- [ ] Attest and verify the dev-release Darwin arm64 archive before it is published or pinned in Homebrew.
- [ ] Make an explicit Harden-Runner decision after an audit-mode experiment or close that item as not worth doing; no repository implementation exists today.

## Remaining scope: dev Darwin attestation

As of `origin/main` commit `21af1719312738b3a52381104c81ca18a74b5510`, the dev-release workflow still publishes `graith-dev_darwin_arm64.tar.gz` and pins its SHA in the generated Homebrew formula, but the only dev attestation job is `attest-linux` and the only publisher provenance step is `Verify Linux build provenance`.

- Add provenance attestation for the exact `graith-dev_darwin_arm64.tar.gz` bytes after the existing Darwin signing, notarization, checksum, and manifest verification has produced the final archive.
- Make `publish-dev` wait for the Darwin attestation as well as the Linux attestations.
- Verify Darwin provenance before `Upload dev release` and therefore before `Update Homebrew tap`, bound to `d0ugal/graith`, signer workflow `d0ugal/graith/.github/workflows/dev-release.yml`, `--source-digest "$RELEASE_REVISION"`, and `--source-ref refs/heads/main`.
- Preserve the current checksum, test, signing, permission, and secret boundaries: only attestation job(s) should receive `id-token: write` and `attestations: write`; the publisher should keep only `attestations: read` for provenance checks.
- Add focused workflow-policy/release coverage proving every archive in the assembled dev release set is attested and fail-closed verified before publication.

## Harden-Runner disposition

No `step-security/harden-runner` coverage exists in the repository as of this reassessment, and recent issue/PR searches did not find an implementation. #1765 covers the broader tool/download provenance inventory and explicitly leaves the missing dev Darwin attestation with this issue; it does not replace runtime egress monitoring.

This remains optional hardening, not a known release-integrity defect. If pursued:

- Start with the smallest release-critical job set in `egress-policy: audit`.
- Pin `step-security/harden-runner` by full commit SHA.
- Keep workflow-lint/actionlint/zizmor and policy tests green.
- Record legitimate egress from a real release before proposing `block`.
- Treat any audit-to-block promotion as a later reviewed change with rollback notes.

If the Darwin attestation lands and runtime egress monitoring is not worth adopting, close the Harden-Runner item with that rationale rather than carrying it as required release work.

Refs #697, #1581, #1765.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in .github/workflows/dev-release.yml by tracing the final Darwin archive through signing, notarization, checksum, manifest verification, attest-linux, and publish-dev. Run the workflow-lint, actionlint, zizmor, and policy tests mentioned in the issue. Done means the Darwin archive is attested and fail-closed verified before publication, with the Harden-Runner audit decision recorded.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, release, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.