blob: ecacd5f6ae65218df29cb343beedde0ac2efca33 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
# Release Verification
Bitflash releases publish binaries and a `SHA256SUMS` file. The checksum file
proves that the file you downloaded matches the file the release page names.
A detached signature, `SHA256SUMS.asc`, proves that the checksum file itself was
signed by a trusted release key.
That gives users two separate checks:
1. `gpg --verify SHA256SUMS.asc SHA256SUMS` checks who signed the checksums.
2. `sha256sum -c SHA256SUMS` checks the binaries against those checksums.
## User Check
From a shell with `curl` or `wget` and `sha256sum`:
```bash
scripts/verify-release.sh latest
```
For a specific release:
```bash
scripts/verify-release.sh v1.2.13
```
For release audits, require the signature:
```bash
scripts/verify-release.sh v1.2.13 --require-signature
```
Older releases may not have `SHA256SUMS.asc`. In that case the script warns and
still checks file integrity. New release audits should use `--require-signature`.
## Maintainer Flow
After building release assets in the repository root:
```bash
scripts/make-release-checksums.sh --sign --local-user RELEASE_KEY_ID
```
Upload all built assets plus:
```text
SHA256SUMS
SHA256SUMS.asc
```
Keep the private signing key offline or on a dedicated release machine. Publish
the public key fingerprint in the release notes and keep using the same key for
future releases unless there is a clearly announced rotation.
## Why This Matters
`SHA256SUMS` alone protects against a broken download, but not against someone
replacing both a binary and the checksum file. Signing `SHA256SUMS` means an
attacker must also have the release signing key to make the replacement verify.
This is not reproducible builds yet. It is the smaller, immediate step that
makes every release asset auditable by users before they run it.
|