You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/release-process.md
+74-77Lines changed: 74 additions & 77 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,19 @@
1
1
# StepSecurity Dev Machine Guard — Release Process
2
2
3
-
This document describes how releases are created, signed, and verified.
3
+
This document describes how releases are created, signed, notarized, and verified.
4
4
5
5
> Back to [README](../README.md) | See also: [CHANGELOG](../CHANGELOG.md) | [Versioning](../VERSIONING.md)
6
6
7
7
---
8
8
9
9
## Overview
10
10
11
-
Releases are created via a manually triggered GitHub Actions workflow (`workflow_dispatch`) that requires approval from the `release` environment. The workflow uses [GoReleaser](https://goreleaser.com/) to:
11
+
Releases are a two-phase process:
12
12
13
-
1. Read the version from `internal/buildinfo/version.go` (`const Version = "1.9.0"`)
14
-
2. Verify the tag does not already exist (immutability)
15
-
3. Build platform-specific binaries with GoReleaser
16
-
4. Sign the binaries with [Sigstore](https://www.sigstore.dev/) cosign (keyless)
17
-
5. Generate SHA256 checksums
18
-
6. Create a Git tag and GitHub Release
19
-
7. Attach binaries, Sigstore bundles, and checksums as release assets
20
-
8. Generate SLSA build provenance attestation
13
+
1.**CI (automated)** — GitHub Actions builds the universal macOS binary, signs it with Sigstore, and creates a **draft** release with the binary named `stepsecurity-dev-machine-guard-VERSION-darwin_unnotarized`.
14
+
2.**Apple notarization (manual)** — Download the binary, sign and notarize it with an Apple Developer account, upload the notarized binary to the draft release, and publish.
15
+
16
+
---
21
17
22
18
## How to Create a Release
23
19
@@ -26,109 +22,110 @@ Releases are created via a manually triggered GitHub Actions workflow (`workflow
26
22
Update `Version` in `internal/buildinfo/version.go`:
27
23
28
24
```go
29
-
constVersion = "1.9.0"
25
+
constVersion = "1.9.1"
30
26
```
31
27
32
-
Update the [CHANGELOG.md](../CHANGELOG.md) with a new section for the version.
33
-
34
-
Commit and push to `main`.
28
+
Update [CHANGELOG.md](../CHANGELOG.md). Commit and push to `main`.
35
29
36
30
### 2. Trigger the release workflow
37
31
38
32
1. Go to [Actions > Release](https://github.com/step-security/dev-machine-guard/actions/workflows/release.yml)
39
-
2. Click **Run workflow**
40
-
3. Select the `main` branch
41
-
4. Click **Run workflow**
33
+
2. Click **Run workflow** on the `main` branch
42
34
43
-
### 3. Approve the release
35
+
The workflow will:
36
+
- Create a git tag (`v1.9.1`)
37
+
- Build a universal macOS binary (amd64 + arm64) via GoReleaser
38
+
- Sign with Sigstore cosign (keyless)
39
+
- Upload as `stepsecurity-dev-machine-guard-VERSION-darwin_unnotarized` to a **draft** release
40
+
- Record the SHA256 of the unnotarized binary in the release notes
41
+
- Generate SLSA build provenance attestation
44
42
45
-
The workflow uses a GitHub Environment called `release` that requires approval. A designated reviewer must approve the run before it proceeds.
43
+
### 3. Apple notarization (manual)
46
44
47
-
### 4. Verify the release
45
+
On a Mac with the Apple Developer certificate installed:
48
46
49
-
Once approved, the workflow will create the tag, build the binaries, sign them, create the GitHub Release, and upload the artifacts. Check the [Releases page](https://github.com/step-security/dev-machine-guard/releases) to confirm.
1.**Tag protection** — configure [tag protection rules](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-tag-protection-rules) in repository settings to prevent tag deletion or overwriting.
118
-
2.**Duplicate tag check** — the release workflow fails if the tag already exists, preventing accidental re-releases of the same version.
119
-
3.**Sigstore transparency log** — every signature is recorded in the public [Rekor](https://rekor.sigstore.dev/) transparency log. Even if an artifact were replaced, verification against the original log entry would fail.
120
-
4.**SLSA build provenance** — the attestation links the artifact to the exact workflow run, commit SHA, and build environment.
0 commit comments