Go toolchain: v1.12.x archive to v1.13.0¶

This document records which Go toolchain built each published v1.12.x release, the Go standard library advisories those binaries carry, what v1.13.0 ships instead, and why an operator on the older line should move. It is a companion to 2026-08-dependency-modernization.md, which covers the toolchain and module changes in the source, and to 2026-09-release-pipeline.md, which measures the same published archives for platform floors and provenance. 2026-03-security-audit.md and 2026-08-security-followup.md cover the CVE remediation in the client’s own code.

Baseline: the four releases v1.12.20 through v1.12.23, published from etclabscore/core-geth, measured by downloading every archive and reading the build information recorded in each binary rather than the configuration that built it. The Linux x86_64 archive of each earlier stable v1.12.x release was measured the same way.

Work carried out by: White B0x

On this page: In short · Why the toolchain needed a pass of its own · Each release from v1.12.20 to v1.12.23 was built by two toolchains · The v1.12.20 to v1.12.23 binaries carry Go standard library advisories · The v1.12.x source does not build on a supported Go · Third-party module advisories were cleared alongside · What a vulnerability scanner reports against v1.13.0 · What this means if you are upgrading · Verification · After v1.13.0 · Disposition of the build finding · Supporting this work

In short¶

Upgrade to v1.13.0 or later. Each release from v1.12.20 to v1.12.23 was built by two Go toolchains, Go 1.21 and Go 1.22, both out of support before those releases shipped. Each of those archives carries 55 to 61 Go standard library advisories, 43 to 47 of them with the vulnerable code present in the binary. Every v1.13.0 archive and image is built with go1.26.8 and carries none.

Why the toolchain needed a pass of its own¶

The Go standard library is compiled into every binary, crypto/tls and net/http included. A Go security release therefore reaches an operator only through a client release built with it, and a binary keeps its toolchain’s advisories for as long as it runs.

The build configuration names a Go version, and the binary records the one that actually built it. go version -m reads that record from a downloaded file without running it. Read from the go-version setting in the release workflow, the v1.12.x releases were built with Go 1.21. Their binaries record two toolchains, and the difference decides which advisories each archive carries.

Finding: each release from v1.12.20 to v1.12.23 was built by two toolchains¶

Every archive of v1.12.20 to v1.12.23 and of v1.13.0, read from the binaries:

21 of the 32 v1.12.x archives were built with go1.22.1, every Arm archive among them. The other 11 were built with Go 1.21. In these four releases the osx archive is an Apple Silicon build, which release artifacts covers; v1.13.0 publishes the two architectures under separate names.

The split follows two build paths in the release configuration, and the pins were the same at all four release commits. The release workflow installed Go with go-version: '1.21' and built the Linux x86_64, macOS and, from v1.12.21, Windows archives with it. The Arm archives were built with build/ci.go install -dlgo, which downloads the Go version pinned in build/checksums.txt: 1.22.1. The v1.12.20 Windows archive came from AppVeyor, which also used -dlgo.

Every v1.13.0 node archive, and geth in the two core-geth-docker image tarballs attached to the release, was built with go1.26.8.

Both older majors are out of support. Go’s release policy: “Each major Go release is supported until there are two newer major releases.”

The 2026 releases shipped after both majors had left support. The toolchains on each release date:

Their Go 1.21 archives carry go1.21.13, the last Go 1.21 release, so nothing newer exists on that branch: every fix published after August 2024 shipped only in newer Go majors. Their Arm archives carry go1.22.1, which was missing seven later security releases on its own branch, and Go 1.22 had no release after February 2025. v1.12.20, published while both majors were still supported, already shipped behind the newest patch of each.

The earlier releases are on unsupported majors as well. The Linux x86_64 archive of every stable release from v1.12.0 to v1.12.19 was measured too. Across those and the 32 above, the 50 v1.12.x archives measured were built with eight Go majors, from Go 1.13 to Go 1.22, and none of them is supported today. Two of those releases shipped on a major that had already left support: v1.12.2 (go1.13.4) and v1.12.10 (go1.18.10).

Finding: the v1.12.20 to v1.12.23 binaries carry Go standard library advisories¶

The Go vulnerability database lists 62 standard library advisories that apply to at least one archive of v1.12.20 to v1.12.23, read with govulncheck against the database snapshot recorded under Verification. Two levels matter:

• Module level: the toolchain version is in the advisory’s affected range, for the archive’s operating system and architecture.
• Symbol level: a function the advisory lists as vulnerable is present in the binary.

Presence is not proof of reachability. Whether the client can reach the vulnerable code was not assessed for any advisory on this page.

Counts are distinct advisories across all archives of a release. “Already published that day” counts those whose database entry was published on or before the release date. All 62 had been published when v1.12.23 shipped. The v1.12.20 count is lower only because most were published after it, and its binaries carry all 62 regardless.

Per archive, in v1.12.23:

From v1.12.21 on, the go1.22.1 archives carry five advisories the Go 1.21 archives of the same release do not. Two were never in a Go 1.21 archive, and go1.21.13 includes the fixes for the other three, which go1.22.1 predates:

Two others depend on the operating system: GO-2025-3750 applies only to Windows, and GO-2026-4864 only to Linux.

The Go vulnerability database assigns no severity to these entries, and this page does not add one.

Finding: the v1.12.x source does not build on a supported Go¶

Rebuilding a v1.12.x release with a supported Go would take the standard library fixes if the source built. It does not. At the v1.12.23 release commit, built with go1.26.6 using the build tags and C flags recorded in the published v1.12.23 binary, the build stops at two independent blockers, in this order.

blst v0.3.11 does not compile from Go 1.24. The release build sets the ckzg tag, as make geth and make all do, and the KZG binding it enables imports blst. The build fails in blst’s Go bindings with cannot define new methods on non-local type SecretKey, and the same error for Fp12, P1Affine and P2Affine. From the Go 1.24 release notes:

The compiler already disallowed defining new methods with receiver types that were cgo-generated, but it was possible to circumvent that restriction via an alias type. Go 1.24 now always reports an error if a receiver denotes a cgo-generated type, whether directly or indirectly (through an alias type).

Upstream go-ethereum moved to blst v0.3.14, whose release carries a fix for Go 1.24, in #31165, first released in go-ethereum v1.15.1.

fjl/memsize does not link from Go 1.23. Without the ckzg tag the build reaches the linker and stops at link: github.com/fjl/memsize: invalid reference to runtime.stopTheWorld. memsize backs the /memsize/ page of the pprof debug server and refers to runtime internals through //go:linkname. From the Go 1.23 release notes:

The linker now disallows using a //go:linkname directive to refer to internal symbols in the standard library (including the runtime) that are not marked with //go:linkname on their definitions.

Upstream go-ethereum removed memsize ahead of Go 1.23, in #30253: “Removing because memsize will very likely be broken by Go 1.23”. That change was first released in go-ethereum v1.14.8.

Removing memsize alone does not produce a build. With the ckzg tag the release configuration sets, the blst compile error comes first on any Go from 1.24. Leaving the tag out as well does produce one, and operators have run v1.12.23 built that way on a current Go.

A toolchain swap alone also keeps Go 1.21’s defaults. The go 1.21 directive in go.mod keeps Go 1.21’s compatibility settings when a newer Go builds the module. All 21 go1.22.1 archives record them:

1

DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1

On a Go from 1.24 on, the same directive switches off two denial-of-service fixes. Go added httpcookiemaxnum, a limit on the cookies net/http parses, and urlmaxqueryparams, a limit on the query parameters net/url parses, as the fixes for GO-2025-4012 and GO-2026-4341. Its compatibility table gives a module declaring a Go older than 1.24 the value 0 for both, which, in the words of Go’s GODEBUG history, accepts “an indefinite number of cookies” and “disables the limit”. go1.26.6 and go1.27.1 carry the same entries. So a v1.12.23 rebuilt on a current Go reports a Go version whose standard library carries those fixes, with both limits off. Setting GODEBUG=httpcookiemaxnum=3000,urlmaxqueryparams=10000 at run time turns them back on.

The previous repository records both blockers. In etclabscore/core-geth:

• #680, an issue opened 2025-04-30, reports that v1.12.20 does not compile with go1.24.0, and its build log shows the blst v0.3.11 errors above. It was closed on 2025-06-29 with the reply “Go 1.24 is not supported, please try Go 1.21”.
• #683, a pull request titled “Support go 1.24 compiler” and opened 2025-06-30, changes go.mod, internal/debug/flags.go, the workflows and the Dockerfiles. Its description says it fixes #680 and #665, an earlier pull request that removes memsize. It was closed without being merged on 2026-02-06.
• #690, an issue opened 2025-11-10, reports the AppVeyor build failing inside blst v0.3.11’s header with 'bool' cannot be defined via 'typedef', and #691, a pull request opened the same day, upgrades blst in go.mod to address it. That failure comes from the C compiler rather than from Go: it is the C23 finding in release artifacts.
• #701, a pull request opened 2026-09-15, removes memsize and its debug endpoint, citing the link error above. On its own that change does not clear the blst error.

v1.13.0 carries blst v0.3.17, no memsize, and go 1.26.0 in go.mod. Its binaries record no DefaultGODEBUG override.

Finding: third-party module advisories were cleared alongside¶

The same scans cover the modules compiled into each binary. In v1.12.23, govulncheck matches 47 advisories against third-party modules at module level, 9 of them at symbol level. 44 are absent from v1.13.0, 3 remain, and none is new. The main module, github.com/ethereum/go-ethereum, is not counted here; the scanner section covers it.

The three that remain are golang.org/x/crypto advisories, described in the scanner section. Four of the 44 also cover the standard library and appear in the list of 62 above. Dependency and toolchain modernization records the module changes themselves.

What a vulnerability scanner reports against v1.13.0¶

Standard library: nothing. No Go standard library advisory applies to any of the nine v1.13.0 archives, or to geth in either core-geth-docker image tarball, even at module level. On 2026-09-17 go1.26.8 was the newest Go 1.26 release, and the last Go 1.26 security release before it was go1.26.6.

Three golang.org/x/crypto advisories, at module level only. v1.13.0 ships golang.org/x/crypto v0.55.0, which is in the affected range of three advisories:

The affected packages are not compiled into any v1.13.0 binary. No golang.org/x/crypto/ssh or golang.org/x/crypto/openpgp function name occurs in any of them, while other golang.org/x/crypto functions do.

The two macOS archives show those three at symbol level. govulncheck reads no symbols from the v1.13.0 osx and osx-arm64 binaries. When it reads none, it handles the binary as stripped and reports every listed vulnerable symbol of every module-level match, so a scan of either archive lists symbol-level golang.org/x/crypto/ssh and golang.org/x/crypto/openpgp findings for code the binary does not contain. Their module-level results are unaffected. The same scanner read symbols from the v1.12.x macOS archives. The v1.13.0 macOS binaries were linked with -s, which removes the symbols it looks for; After v1.13.0 gives the detail and the change.

Six go-ethereum advisories, all fixed in v1.13.0. Every v1.13.0 archive matches six advisories filed against go-ethereum, at symbol level, and the match is structural. The Go module path is deliberately github.com/ethereum/go-ethereum, which is what makes this client a drop-in downstream. The scanner compares this client’s version with go-ethereum’s version ranges, and v1.13.0 sorts below the go-ethereum releases that fixed these, so each one matches whether or not its fix is present. Matching on symbol names does not settle it either, because a backported fix adds its guard inside the same function. Release artifacts describes how to read such a scan. Each match was confirmed by reading the guard at the v1.13.0 tag:

What this means if you are upgrading¶

• Rebuilding a v1.12.x release on a newer Go takes the standard library fixes, but not all of what upgrading does. The build needs memsize removed and the KZG build tag left out. It still declares go 1.21, so two denial-of-service limits stay off unless GODEBUG sets them, and it keeps the third-party module advisories and everything else v1.12.23 carries. v1.13.0 declares go 1.26.0 and is built with go1.26.8.
• Arm builds of v1.12.x carry the most. Every Arm archive from v1.12.20 to v1.12.23 carries 61 standard library advisories at module level.
• Go 1.26 is supported until go1.28.0 is released, under the policy above. A Go security release reaches your node only through a Core-Geth release built with it, so follow the ethereumclassic/core-geth release line.

Verification¶

Each check below was calibrated so that it could report a negative:

• The published files. 59 node archives were downloaded: every archive of v1.12.20 to v1.12.23 and v1.13.0, and the Linux x86_64 archive of each earlier stable v1.12.x release. Each matched its published .sha256, and the 33 from 2026 releases also matched GitHub’s server-side digest, which the older release assets do not carry. Both v1.13.0 core-geth-docker image tarballs matched as well.
• The source they came from. Each binary’s recorded vcs.revision equals the commit its release tag points to.
• The toolchain. Read from each binary’s build information with go version -m. No downloaded binary was executed.
• The advisories. govulncheck v1.7.0 in binary mode, at symbol level and at module level, on all 41 binaries of v1.12.20 to v1.13.0, against one snapshot of the Go vulnerability database for every scan: vuln.go.dev as modified 2026-09-15T18:39:25Z, 4,445 entries, SHA-256 fe51e51645e6b1e946731cef048339972256c6417de91d4cf3985fc87b4aa89b.
• Calibration in both directions. Every v1.12.20 to v1.12.23 binary reports 55 to 61 standard library advisories at module level, and a Go binary built with go1.26.1 reports 28, fixed in go1.26.2 to go1.26.6. A Go binary built with go1.26.6 reports none.
• An independent re-derivation. Each advisory’s version ranges were evaluated directly against each binary’s Go version and module versions, excluding withdrawn entries and applying the same operating system and architecture filter as govulncheck. The result matched govulncheck’s for all 41 binaries, including the first fixed Go version of every standard library match.
• Whether the scanner read symbols. govulncheck read between 49,101 and 53,753 symbols from 39 of the 41 binaries, and none from the two v1.13.0 macOS binaries described above. The absence of golang.org/x/crypto/ssh and golang.org/x/crypto/openpgp function names was checked in all 41, against other golang.org/x/crypto names present in every one.
• Release-date counts. “Already published that day” uses each advisory’s published date. Counting instead by the release date of the first Go version that fixes it gives the same figure for every archive of every release.

• The failed build. At the v1.12.23 release commit, with go1.26.6 and modules verified against its go.sum, this command exits 1 with the blst compile error, and the same command without the ckzg tag exits 1 at the link step with the memsize error:

  1	GOTOOLCHAIN=local CGO_CFLAGS="-O2 -g -D__BLST_PORTABLE__" go build -p 4 -tags urfave_cli_no_docs,ckzg ./cmd/geth

Not measured:

• The core-geth-alltools archives and image tarballs, so the go1.26.8 result for v1.13.0 is established for geth only.
• Container images published to a registry, for any release, including v1.12.x images built from golang:1.22-alpine.
• Archives of v1.12.0 to v1.12.19 other than Linux x86_64, and govulncheck on any of them.
• Prereleases and drafts.
• Builds on Go 1.23, 1.24, 1.25 or 1.27. The Go release each blocker arrived in comes from Go’s release notes and source, not from building on it.
• Reachability of any advisory from the client’s code paths.
• go-ethereum advisories against the v1.12.x binaries. Those record the main module’s version as (devel), which govulncheck never matches, so their absence is not evidence either way.
• Why the release workflow’s go-version: '1.21' produced go1.21.10 on 2024-06-10, when go1.21.11 had been released on 2024-06-04, and how the v1.12.2 Linux archive came to be built with go1.13.4.
• Issues and pull requests in etclabscore/core-geth beyond those listed above, which were found by search and screened by title.

After v1.13.0¶

Each of these is resolved on main for the next release. None changes what v1.13.0 ships or how it behaves.

• Dependency maintenance. golang.org/x/crypto moves to v0.56.0, which fixes GO-2026-6354 and GO-2026-6355 in golang.org/x/crypto/ssh, and golang.org/x/mod to v0.40.0, which fixes GO-2026-6179 and GO-2026-6180 in golang.org/x/mod/sumdb. v1.13.0 compiles none of those packages into any binary, so they are not a concern for v1.13.0. GO-2026-5932, in golang.org/x/crypto/openpgp, has no fixed version and is not compiled in either.
• A weekly scan. .github/workflows/govulncheck.yml scans main every week, in source mode and against a geth binary built with the release Go version, and keeps one issue current with anything that needs a maintainer. The six go-ethereum advisories above are expected; one of them disappearing is reported too.
• The macOS symbol table. The release build linked the macOS binaries with -s, which removes Go’s symbols from the Mach-O symbol table. govulncheck looks up the go:func.* symbol there and, without it, reports at module level, although the __gopclntab function table it reads next is present. build/ci.go now links them with -w, which strips only the debugging information. A go1.26 macOS test binary linked with -w keeps go:func.* and every Go symbol; one linked with -s keeps none.

Disposition of the build finding, 17 September 2026¶

The finding that the v1.12.x source does not build on a supported Go now has a proposed remedy in the repository that publishes that line. Pull request #702 at etclabscore/core-geth, opened 17 September 2026 and unmerged when this was written, makes the three changes this audit measured as necessary: it removes github.com/fjl/memsize, whose //go:linkname use Go 1.23 restricted; it moves github.com/supranational/blst from v0.3.11, which Go 1.24 rejects for a cgo alias receiver, to v0.3.16; and it raises the go.mod directive from go 1.21 to go 1.24.0. It also moves the # version:golang pin in build/checksums.txt from 1.22.1 to 1.25.12 and updates golang.org/x/crypto from v0.17.0 to v0.48.0.

Two measurements to repeat rather than assume, if that release ships. Go 1.24 left support on 10 February 2026 and Go 1.25 on 19 August 2026, each when two newer major releases existed, so a binary built from either would still carry standard library advisories, fewer than Go 1.21 carries. And the advisory count for any such release has to be measured from its published archives, the way the counts in this document were, rather than inferred from the go.mod directive: this audit found two toolchains per release where the configuration implied one.

This paragraph records a disposition, which is what an audit finding is supposed to acquire. It is not a claim about anyone’s reasons.

Supporting this work¶

The modernization this document records was carried out by White B0x as unfunded public-goods work for Ethereum Classic. Mining pools, centralized exchanges, issuers of Ethereum Classic financial products, Etchash mining hardware manufacturers and large holders all depend on this client. If your operation relies on Ethereum Classic, please help fund its maintenance. Support this work has the routes: sponsorship on GitHub, an invoiced agreement for organizations, or a direct transfer.