nordisk/gunnar

Releasing Gunnar

How a Gunnar release is made, step by step. The build, the provenance and how anyone can verify a release are described in full in docs/SLSA.md.

1. Version. The version follows Semantic Versioning (see CHANGELOG.md). The crates' versions are raised in their Cargo.toml, and every lock follows.
2. Changelog. The Unreleased section of CHANGELOG.md becomes the release's section, with every fixed vulnerability named by its id under "Security".
3. Green. cargo xtask ci is green on the release commit, and the dwarves forge's CI run for that commit is green (https://gunnar.rs/nordisk/ci-status).
4. Build. The release is built by the dwarves forge's release-build pipeline from the commits named in the release spec, in sealed containers with no network, and the forge writes the SLSA provenance.
5. Sign. The release manager signs the provenance statement with the release key on a YubiKey (slsa/README.md); the private key never leaves the YubiKey and is never on a build or distribution machine.
6. Tag. The release commit gets an annotated tag v<version>.
7. Publish. Each crate is published to crates.io only if its sha256 is the one the signed provenance names.
8. Verify. Anyone can verify a release with the committed release key, as shown in docs/SLSA.md.

Only the latest release line gets fixes (SECURITY.md, "Supported versions"); an upgrade path between versions is written in the CHANGELOG.