Eli Schwartz <[email protected]> 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
signature.asc
Description: PGP signature
