From bfd95d681f5fc6329a89596be2c1194dc03dfebc Mon Sep 17 00:00:00 2001 From: GeiserX <9169332+GeiserX@users.noreply.github.com> Date: Mon, 14 Sep 2026 09:18:22 +0200 Subject: [PATCH] ci: pin Go to exact 1.26.8 so release builds are reproducible #135 loosened go-version from '1.26.5' to '1.26' so setup-go would track the latest 1.26.x and pick up stdlib security releases automatically. That trades reproducibility for convenience: a release rebuilt later may compile with a different toolchain than the one that shipped. Pin the exact patch in all three places (ci.yml twice, desktop-release.yml once). 1.26.8 is the current 1.26.x, two patches past the 1.26.6 that #135's control run resolved, so this is not a rollback to a vulnerable toolchain. The govulncheck hard gate is what stops an exact pin from rotting: it runs on the pinned toolchain, so a reachable stdlib advisory fails CI on the next PR and prompts a bump. SECURITY-NOTES.md now describes that policy instead of the floating one. --- .github/workflows/ci.yml | 4 ++-- .github/workflows/desktop-release.yml | 2 +- docs/SECURITY-NOTES.md | 13 +++++++++---- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index f98290e..b46df7f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -22,7 +22,7 @@ jobs: persist-credentials: false - uses: actions/setup-go@v7 with: - go-version: '1.26' + go-version: '1.26.8' cache: true - name: Build run: go build ./... @@ -88,7 +88,7 @@ jobs: persist-credentials: false - uses: actions/setup-go@v7 with: - go-version: '1.26' + go-version: '1.26.8' cache: true - name: Install govulncheck run: go install golang.org/x/vuln/cmd/govulncheck@latest diff --git a/.github/workflows/desktop-release.yml b/.github/workflows/desktop-release.yml index ea3953f..17ddceb 100644 --- a/.github/workflows/desktop-release.yml +++ b/.github/workflows/desktop-release.yml @@ -34,7 +34,7 @@ jobs: - uses: actions/setup-go@v7 with: - go-version: '1.26' + go-version: '1.26.8' cache: true - uses: actions/setup-node@v7 diff --git a/docs/SECURITY-NOTES.md b/docs/SECURITY-NOTES.md index 01ae04c..5b92bc8 100644 --- a/docs/SECURITY-NOTES.md +++ b/docs/SECURITY-NOTES.md @@ -7,11 +7,16 @@ present in the dependency tree. The job is a hard gate: a finding our code can r ## Go standard library -The release and CI workflows ask for `go-version: '1.26'`, so `setup-go` resolves the latest 1.26.x patch -and each Go security release arrives without a workflow edit. Keep it that way. Pinning an exact patch -looks tidy and then quietly rots: the workflows sat on `'1.26.5'` while go1.26.6 fixed five advisories our +The release and CI workflows pin an exact toolchain, `go-version: '1.26.8'`, so a release built today and one +rebuilt next month use the same compiler and standard library. The cost of an exact pin is that Go security +releases do not arrive on their own: the workflows sat on `'1.26.5'` while go1.26.6 fixed five advisories our code actually calls (`GO-2026-6218` net/url, `GO-2026-6090` crypto/tls, `GO-2026-6089` and `GO-2026-5026` -net/http, `GO-2026-5972` encoding/asn1), which shipped in release binaries until the gate caught it. +net/http, `GO-2026-5972` encoding/asn1), and those shipped in release binaries until the gate caught it. + +The `govulncheck` gate is what keeps the pin honest. It runs against the pinned toolchain, so a stdlib advisory +our code can reach fails CI on the next pull request. When it does, or when a Go security release ships, bump +the pin in all three places (`ci.yml` twice, `desktop-release.yml` once) to the latest 1.26.x and let the gate +confirm it. If you build locally with an older toolchain you will see those findings. Update your Go toolchain.