Skip to content

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

Open
tannevaled wants to merge 1 commit into
mainfrom
go127
Open

tannevaled wants to merge 1 commit into
mainfrom
go127

Conversation

@tannevaled

Copy link
Copy Markdown
Contributor

One line of go.mod (and, where CI pinned an older patch, that too). The reason is measured.

What was inconsistent

The go directive said 1.26.4; CI was already building with 1.27. The
version declared and the version tested 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

govulncheck on the one repository of this stack whose pin was still "1.26"
(go-images/jpeg2000#28) — 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, because a count is not a
finding:

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 reports no vulnerabilities for this module under 1.27.1.

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 and whatever coverage gate this repository has all pass
under 1.27.1. 1.27's gofmt wants nothing this tree does not already have —
checked against the toolchain module cache rather than the local go, because
another session upgraded Homebrew's Go from 1.26.4 to 1.27.1 in the middle of
the measurement, which makes "the local toolchain" an unstable reference.

🤖 Generated with Claude Code

The go directive said 1.26.4 while every lane of this repository's CI pins
go-version 1.27.1, so the version DECLARED and the version TESTED 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 whose 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 either 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.

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

go vet and the whole suite pass under 1.27.1, and 1.27's gofmt wants
nothing this tree does not already have -- checked against the toolchain
module cache rather than the local go, which another session upgraded from
1.26.4 to 1.27.1 mid-measurement.
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