Repository navigation
Use one Go version, 1.27.3, for CI and releases - #389
Merged
Merged
Conversation
mbyczkowski
marked this pull request as ready for review
October 26, 2026 21:42
randradesq
approved these changes
Oct 26, 2026
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.
Why
v1.18.1 was built with Go 1.27.1, and master still pins that version for releases. govulncheck finds 9 standard library vulnerabilities that certigo code reaches with Go 1.27.1, and none with 1.27.3.
The most important one is GO-2026-6809 (CVE-2026-111943, golang/go#82345). Go 1.27.3 adds a
crypto/x509denylist of compromised intermediate certificates from one CA.certigo verifyandconnectcallx509.Certificate.Verify(lib/verify.go:148). Built with Go 1.27.1, certigo can report a chain through one of those intermediates as valid. Most of the others arenet/httpand HTTP/2 fixes in 1.27.2.Each workflow also chose its Go version differently. Releases and the compile check pinned an exact version in two places that had to be kept in sync. Tests and lint used the newest stable Go, so a new Go release could break CI on its own, as Go 1.27.2 did to lint (#387).
What
Build and test everything with Go 1.27.3, from one
.go-versionfile, for v1.18.2.How
.go-versionwith1.27.3. Every workflow reads it withgo-version-file: release, compile check, unit, integration and JCEKS tests, and lint.GOTOOLCHAIN=localin every workflow, so Go never downloads a different toolchain than the one.go-versionnames.go 1.26.0. Raising it to 1.27 would change the main module's GODEBUG defaults. In particular,x509sslcertoverrideplatformwould make certigo load roots fromSSL_CERT_FILE/SSL_CERT_DIRon macOS and Windows instead of the platform store.To update Go, change
.go-version. If lint then fails to type-check, bump golangci-lint in the same PR.Risk
Tests and lint no longer pick up new Go releases automatically. A Go update is now a deliberate one-line PR. Compile check job names drop the version, for example
Compile Check (darwin, macos-latest, amd64). They aren't required checks.Testing
go vetand the unit tests pass, and the linux/amd64, darwin/arm64 and windows/amd64 builds succeed.🤖 Generated with Claude Code