Skip to content

go 1.27.1, which is what CI has been building with - #109

Merged
tannevaled merged 1 commit into
mainfrom
go127
Oct 4, 2026
Merged

tannevaled merged 1 commit into
mainfrom
go127

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

One line of go.mod, and the reason is measured.

What was inconsistent

The go directive said 1.26.4 while every lane of this repository's CI pins
go-version: "1.27.1". The version the module declared and the version it
was tested with had not been the same for weeks, and a consumer reading
go.mod was told it could build this with a toolchain nothing here exercises.

The security case, measured on a sibling

go-images/jpeg2000 still pinned "1.26", so it is where the difference could
be measured. govulncheck, same code, two toolchains:

toolchain in packages imported in modules required
go1.26.4 1 10
go1.27.1 0 0

Nothing was ever called — "your code is affected by 0 vulnerabilities" in both
— so this is what the toolchain carries. Named:

os@go1.26.4      GO-2026-4970                       fixed in go1.26.5
stdlib@go1.26.4  GO-2026-6218 6091 6090 6089 6088
                 5972 5942 5026                     fixed in go1.26.6
                 GO-2026-5856                       fixed in go1.26.5

govulncheck on this module is silent under 1.27.1: golang.org/x/sys is
already v0.48.0 here, which is past GO-2026-5024.

Why 1.27.1 and not 1.27

That is the style this file already used, and the advisories above are
patch-level: go 1.27 would admit a toolchain with none of 1.27.1's fixes.

Checks

go vet, the whole suite, exact 100% coverage and gofmt all pass under
1.27.1 — which is the toolchain CI already uses. This changes what is
declared, not what is tested.

Independent of #103, #105, #106 and #107; touches go.mod only.

🤖 Generated with Claude Code

The go directive said 1.26.4 while every lane of this repository's CI
pinned go-version 1.27.1 -- so the version the module DECLARED and the
version it was tested with had not been the same for weeks, and a consumer
reading go.mod was told it could build this with a toolchain nothing here
exercises.

The security case is measured, on a sibling of this module where the pin
was still 1.26 (go-images/jpeg2000#28). govulncheck, same code:

    toolchain   in packages imported   in modules required
    go1.26.4              1                    10
    go1.27.1              0                     0

Nothing was CALLED in any case. What 1.26.4 carries is its own standard
library: GO-2026-4970 in os, and GO-2026-6218, 6091, 6090, 6089, 6088,
5972, 5942, 5026 and 5856 in stdlib, fixed across 1.26.5 and 1.26.6.
govulncheck on THIS module is silent under 1.27.1 -- x/sys is already
v0.48.0 here, which is past GO-2026-5024.

A patch-level directive, 1.27.1 rather than 1.27, because that is the
style this file already used and because the advisories above are
patch-level: "1.27" would admit a toolchain that has none of 1.27.1's
fixes.

go vet, the whole suite, exact 100% coverage and gofmt all pass under
1.27.1, which is the toolchain CI already uses -- so this changes what is
declared, not what is tested.
@tannevaled
tannevaled merged commit 500c1d9 into main Oct 4, 2026
9 checks passed
@tannevaled
tannevaled deleted the go127 branch October 4, 2026 19:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant