Your browser sucks, JavaScript disabled! Gunnar's console needs JavaScript and WebAssembly. Git over SSH on port 2222 does not.

nordisk/holger

RELEASING.md

Releasing Holger

How a Holger release is made, step by step. The build, the provenance and how anyone can verify a release are described in full in docs/v2/08-supply-chain.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. The media, the app archives and the binaries get a statement of their own, cargo xtask release-attest --release holger-<version>, checked with --check and signed the same way (docs/v2/07-build-thing.md).
  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/v2/08-supply-chain.md.

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