[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mrz1tbu3.fsf@gentoo.org>
Date: Sat, 18 Apr 2026 00:18:44 +0100
From: Sam James <sam@...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
Eli Schwartz <eschwartz@...too.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
Download attachment "signature.asc" of type "application/pgp-signature" (419 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.
