chore(go): Move to Go 1.26 and split minimum from build toolchain

[korya]

Problem

Released binaries were built with a Go toolchain eight months stale, missing seven patch releases of crypto/tls and net/http security fixes.

The published v0.2.0 artifact reports go1.25.5, released 2025-12-02. Every release from go1.25.6 through go1.25.12 carried security fixes, several to the exact packages this tool is built on — crypto/tls, net/http, net/url.

The cause is that go.mod pinned an exact patch and the workflows install whatever version go.mod names. One value served two unrelated roles: the minimum Go this module supports, and the compiler that builds and ships it. Nothing signalled when they diverged, because GOTOOLCHAIN=auto quietly downloaded a second toolchain to paper over the gap.

That coupling also lets a third party's Go floor break the build. gosec raised its requirement to go1.25.8, and #67 — which bumps actions/setup-go to v7, where GOTOOLCHAIN=local disables the silent download — went red:

go: github.com/securego/gosec/v2@v2.28.0 requires go >= 1.25.8
    (running go 1.25.5; GOTOOLCHAIN=local)

Solution

Split go.mod's single version into two directives: go 1.26 for the minimum supported, toolchain go1.26.5 for what actually builds.

 module github.com/korya/http-assert

-go 1.25.5
+go 1.26
+
+toolchain go1.26.5

Role	Before	After
Minimum Go the module supports	go 1.25.5	go 1.26
Toolchain CI and releases build with	go 1.25.5 (same value)	toolchain go1.26.5
What happens when a dev tool raises its Go floor	project minimum moves, or CI breaks	nothing

1.26 is the line to be on: Go supports a release until two newer ones exist, and go1.27rc2 is already published, so 1.25 stops receiving backports the moment 1.27 ships.

Why an exact patch rather than go-version: 'stable'. .goreleaser.yaml deliberately pursues reproducible builds — -trimpath and mod_timestamp exist so two builds of one commit produce one checksum. The Go version is stamped into the binary, so a compiler free to drift would undo that. Two builds at a fixed toolchain do produce identical sha256; letting the compiler float would have quietly dismantled a property the config's own comments defend.

The directive is a floor, not a ceiling. A machine with a newer Go runs that instead. Releases are exact anyway because setup-go installs the version the directive names and then sets GOTOOLCHAIN=local, disabling switching altogether — so that guarantee arrives with #67, and until then a release build tracks the newest 1.26 patch.

The pin cannot upgrade itself, which is the original failure in slower form. just toolchain-check reports when the pin trails its patch line, as a warning that exits zero — a new Go patch is not a defect in this repository, and a red build every six weeks teaches everyone to skip past it. It lives in the Justfile so CI and a developer's machine run one implementation, as every other check here already does.

Together these unblock #67: 1.26.5 clears gosec's floor, so that PR goes green on a rebase with no edits to it.

Other Changes

• README.md now states the Go requirement on the source-install section, which previously sent readers to go install without saying what it needed. The --version sample's go1.25.5 was refreshed, since the pin makes it untrue of anything built from this commit.
• No visual change — this is a CLI and CI change with no rendered UI.
• version_test.go keeps its go1.25.5 fixtures deliberately: they are supplied debug.BuildInfo inputs, not reads of the live toolchain, so changing them would be diff noise.

Related:

• chore(deps): Bump actions/setup-go from 5 to 7 #67

🤖 Generated with Claude Code