[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <545dcd82-c8f3-4702-ae81-8b5207791d95@gentoo.org>
Date: Fri, 17 Apr 2026 15:04:04 -0400
From: Eli Schwartz <eschwartz@...too.org>
To: oss-security@...ts.openwall.com
Subject: Re: Go 1.26.2 and Go 1.25.9 are released with 10
security fixes
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.
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?
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.)
--
Eli Schwartz
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
