Re: Go 1.26.2 and Go 1.25.9 are released with 10 security fixes

[Sam James <sam () gentoo org>]

Eli Schwartz <eschwartz () gentoo org> writes:

> On 4/17/26 6:30 AM, Matthias Ferdinand wrote:
> > On Fri, Apr 10, 2026 at 04:58:03AM +0200, Solar Designer wrote:
> > > On Wed, Apr 08, 2026 at 04:24:34PM -0700, Alan Coopersmith wrote:
> > > > https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU announces:
> > > > > We have just released Go versions 1.26.2 and 1.25.9, minor point releases.
> > > > >
> > > > > These releases include 10 security fixes following the security policy:
> > >
> > > This includes 2 issues in the compiler itself, which made some Go
> > > programs not memory safe:
> >   ...
> >
> >
> > I did not see any Linux distribution advisories for compiled Go programs
> > yet, but some projects using Go have released upates:
> >
> >   - https://rclone.org/changelog/#v1-73-4-2026-04-08
> >         Update to go 1.25.9 to fix multiple CVEs
> >
> >   - https://github.com/grafana/grafana/releases/tag/v12.4.3
> >         2026-04-14: Go: Update to 1.25.9
> >
> > I looked at https://github.com/gopasspw/gopass and
> > https://github.com/restic/restic, but they have not yet issued updated
> > releases.
> >
> > Perhaps the message did not spread wide enough. Or are many Go programs
> > just not affected?
>
>
> Updated *releases* don't really make sense, generically. The bug is in
> the compiler, not the package, so one would rebuild the existing release
> with a new compiler. Consider how you handle this if a package had a
> security vulnerability in the GCC version it was compiled in. Or, it
> depended on libarchive and libarchive had a security release. Do you tag
> a brand new version of rclone because the dependencies it was compiled
> against got updated? No. Well, given gomodules or rust crate locking,
> maybe, because those are "vendored libraries", but that is a bug in both
> of those languages. :)
>
>
> If I look at rclone, I see they only updated go 1.25.9 in the CI
> workflow that builds precompiled binaries and attaches them as github
> releases assets. The actual rclone release was noteworthy more for
> fixing a denial of service that required pulling in a newer version of a
> vendored library.

For serious issues, it may make sense for projects distributing binaries
(provided they know it was built by a buggy compiler) in the same way
they might do for a vulnerable OpenSSL DLL in their Windows offering.

But yes, I agree, it'd be pretty annoying if every Go piece of software
issued a new release that was a no-op and was just there to nudge you to
rebuild it.

> On the compiler side of things, Gentoo Linux policy is to offer a
> standard approach to rebuilding all packages that use golang:
>
> $ emerge @golang-rebuild
>
> which should be run after all golang updates that one suspects deserve a
> global rebuild. Likely all golang updates because Reasons(tm). This is
> just the name of the game when installing golang software -- the usual
> rule of thumb is to assume all golang releases contain CVEs that need
> fixing. It is regular like clockwork, so do people really need an
> invitation to do so?

Right, the stdlib case is pretty common.

> Other distros should be bumping the build number and recompiling the
> package in place, using the same infrastructure otherwise used for
> things like rebuilding ten thousand packages against a new major edition
> of perl or python or ruby.
>
> IIRC it is possible to determine which packages actually need rebuilding
> for any given CVE, but to do so you need to locally extract the entire
> recursive deps-included source code of every package, and run some
> arcane undocumented `go ....` invocation. Functionally, what you're
> doing is checking which programs link to an internal static library
> distributed with the go compiler. (This is not exactly correct, but it
> is a useful mental model.)

sam

Attachment: signature.asc
Description: