Skip to content

v4.8.2 — Go 1.27.3, a floor for every program that can use TLS

Latest

Choose a tag to compare

@andygeiss andygeiss released this 21 Oct 16:58
· 1 commit to main since this release

A security pin. Go 1.27.3 stops crypto/x509 trusting a handful of intermediate certificates, and below it govulncheck fails every program that can use TLS.

The pin moves to Go 1.27.3. It shipped on 2026-10-19 with one advisory, GO-2026-6809, on Go's urgent track: Certificate.Verify now drops every chain through a small set of intermediate certificates Go no longer trusts (go.dev/issue/82345). VERSIONS.md, the pin line in stack/go.md, and both GOTOOLCHAIN commands in operations/ci.md moved together. The 1.27.3 source differs from 1.27.2 only inside crypto/x509, with no API change, so the canonical snippets were not re-run under it.

Who fails below the floor. The 1.27.2 floor caught every web application. This one catches every program that can reach Certificate.Verify, and every TLS handshake can. Under 1.27.2, a program whose only network call is http.Get fails, even to an http:// address, and so does one that only calls smtp.SendMail, tls.Dial or ListenAndServeTLS, or Certificate.Verify with no TLS at all. A program that only serves plain HTTP passes, and so does an SMTP client that never calls SendMail or StartTLS. The reference fails, from cmd/server. Under 1.27.3 all of them pass. The Go row says it in the bytes the old row took: every program that can use TLS, as every net/http client can.

What review found. Four rounds of two adversarial passes read the pin and executed its claims under both toolchains, with throwaway modules on each side of the line. They found 7, 1, 1 and 0 distinct defects. The one that mattered was in the first draft of the Go row: it said 1.27.2 fails "every program with an HTTP or SMTP client", which was false both ways, since SMTP without TLS passes and a bare tls.Dial fails. Round two found the record still treating TLS as the trigger rather than the call. The rest were in the record:

  • two commit messages that said less or more than their diffs;
  • an "it" that named the old pin and then govulncheck;
  • a reason for keeping four 1.27.1 lines that held for one of them;
  • the libc question, which had dropped out of the date bullet;
  • an Owed promise that this run would read round four's fixes, which Andy then chose it would not;
  • and that choice, recorded at first without what it means for the gate.

This release does not meet the gate's first condition for operations/ci.md. Andy chose to review it on its Go pin alone, and the last two passes came back clean. But the pin changes two lines of operations/ci.md, which also carries round four's fixes from v4.8.1 (aafa39f), and no pass has read those. VERIFICATION.md keeps them owed to the next run.

Not in this release. The child-process pattern sat out this tag as it sat out v4.8.0 and v4.8.1, and it is back on main in the commit after, still owed a run with round five's ten findings open. VERSIONS.md keeps its 2026-09-08 date: htmx 2.0.11 and modernc.org/sqlite v1.61.0 have shipped, and with the exact modernc.org/libc the driver names, which go get -u ./... moves, they wait for one ruling.

Budgets: no floor, change path or reach moves. The new Go row is as long as the old one, byte for byte.

Reference: baseline-reference v4.8.2, pinning c79c209: ./verify.sh exits 0 over 79 gates and make ci is green, both under Go 1.27.3. Under 1.27.2, ./verify.sh stops at its fifth step, govulncheck.