fix(deps): require go 1.26.6 to close four reachable stdlib vulnerabilities - #328
Merged
Merged
Conversation
…lities Closes #327. `govulncheck` has been red on the scheduled `audit.yml` run since 2026-08-17, reporting four standard library vulnerabilities my code calls: GO-2026-6218 (`net/url`), GO-2026-6090 (`crypto/tls`), GO-2026-5972 (`encoding/asn1`) and GO-2026-5026 (`net/http` via `x/net/idna`). All four are fixed in go 1.26.6 and the directive declared 1.26.5, so raising it is the whole remediation: the directive is the floor toolchain selection honours, which is what puts a consumer on a patched standard library. Reach, stated rather than dressed up: all four are resource exhaustion or parser hardening, none is an authentication break, and three of them sit on the outbound leg of the OAuth token exchange, where exercising one means being the provider or sitting between the consumer and it. GO-2026-5972 is the one that is not on the wire. `decodeEd25519PublicPEM` parses key material that arrives through `Config.PreviousPublicKeys` or a `KeyStore` on the rotation path, so a deeply nested DER blob reaches `asn1.Unmarshal` from configuration. ### What I measured | Check | go 1.26.5 | go 1.26.6 | |---|---|---| | `govulncheck ./...` | exit 3, 4 vulnerabilities my code calls | exit 0, **No vulnerabilities found** | | `go test -race ./...` | | 9/9 packages pass | | Nine examples, `go build && go vet` | | 9/9 pass, one package each | The 1.26.5 column is a control run, not the CI log: I put the directive back, re-ran, and read the same four advisories before restoring 1.26.6. Without it a clean scan proves only that the scan ran. The toolchain selected 1.26.6 on its own once the directive moved, and `go env GOWORK` is still empty at the repository root, so the library is tested against the versions it declares rather than the ones gin and fiber elevate. ### Two things this does not change `GO-2026-5932` against `golang.org/x/crypto` still shows as a vulnerability in a module I require but do not call. It is the standing advisory that `x/crypto/openpgp` is unmaintained and unsafe by design, `Fixed in: N/A`, applying to every version of the module since 0. Nothing here imports `openpgp`. The examples move with the root because the workspace pins one toolchain across all ten modules; `examples.yml` reads `go-version-file` per example, so leaving them behind would have run CI on a floor the library no longer declares. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com>
This was referenced Sep 7, 2026
Merged
Jaro-c
added a commit
that referenced
this pull request
Sep 7, 2026
…11.8 (#330) Supersedes #281, #282, #283 and #284. Closing those four in favour of this one. They had been open since 2026-08-17, and two of them would have landed a repository that was already behind on the day it merged: #281 proposes `golang.org/x/crypto` v0.55.0 when v0.56.0 is out, and #284 pins the nine examples to `authcore` v1.11.7 when v1.11.8 shipped this morning. Re-landing the same four bumps at the versions that are actually current costs one branch and avoids merging a correction that needs correcting. ### What moves Root, still five direct dependencies: | Module | From | To | |---|---|---| | `golang.org/x/crypto` | v0.54.0 | v0.56.0 | | `golang.org/x/net` | v0.57.0 | v0.58.0 | | `golang.org/x/text` | v0.40.0 | v0.41.0 | Examples: `authcore` v1.11.6 to v1.11.8 in all nine, and `gofiber/fiber/v3` v3.4.0 to v3.5.0 in the fiber example, which carries `fasthttp`, `klauspost/compress` and `mattn/go-isatty` with it. `gin` was already on v1.12.0, the current release. ### What I measured | Check | Result | |---|---| | `govulncheck ./...` | exit 0, **No vulnerabilities found** | | `go test -race ./...` | 9/9 packages pass | | Nine examples, `go build && go vet` | 9/9 pass, one package each | | `go` directive, all 11 module files | untouched at 1.26.6 | One latent entry remains, in a module I require but do not call: the standing `GO-2026-5932` advisory that `x/crypto/openpgp` is unmaintained and unsafe by design, `Fixed in: N/A`, applying to every version of the module since 0. Nothing here imports `openpgp`. ### Three files this deliberately does not add `go mod tidy` under `GOWORK=off` wrote a `go.sum` into the apikey, basic and username examples, which have never carried one. Those three depend on nothing but `authcore`, and the workspace resolves it from the checkout, so there is no hash to record. I deleted them and confirmed all three still build and vet. Committing them would add three files that every future bump has to keep in step, which is the coupling the workspace removed. ### Release This changes a dependency floor, which the releases standard counts as something a consumer receives, so it wants a tag rather than sitting on `develop`. It is not urgent the way #328 was: `govulncheck` was already clean at v1.11.8, so nothing here closes an open advisory. Signed-off-by: Jaro-c <75870284+Jaro-c@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #327.
govulncheckhas been red on the scheduledaudit.ymlrun since 2026-08-17, reporting four standard library vulnerabilities my code calls. All four are fixed in go 1.26.6 while the directive declared 1.26.5, so raising it is the whole remediation: the directive is the floor toolchain selection honours, which is what puts a consumer on a patched standard library. Same shape as #216 and #172, both of which shipped as PATCH releases.Eleven files, one line each: the root module, the nine example modules, and
examples/go.work. The examples move with the root becauseexamples.ymlreadsgo-version-fileper example, so leaving them behind would run their CI on a floor the library no longer declares.What I measured
govulncheck ./...go test -race ./...go build && go vetThe 1.26.5 column is a control run rather than the CI log: I put the directive back, re-ran, read the same four advisories, then restored 1.26.6. Without that column a clean scan proves only that the scan ran.
The toolchain selected 1.26.6 on its own once the directive moved, and
go env GOWORKis still empty at the repository root, so the library is tested against the versions it declares rather than the ones gin and fiber elevate.What this leaves alone
GO-2026-5932againstgolang.org/x/cryptostill shows as a vulnerability in a module I require but do not call. It is the standing advisory thatx/crypto/openpgpis unmaintained and unsafe by design,Fixed in: N/A, applying to every version of the module since 0. Nothing here importsopenpgp.After this merges
audit.ymlgoes green on its next Monday run, which clearsaudit freshness / schedule freshnessand takes the nine pin bumps (#316 to #324) out ofUNSTABLE. v1.11.7 is whatgo getserves today, so this wants a PATCH release rather than riding along with the next one.