[ hopefully, discussing binary releases is not off-topic ] On Sat, Apr 18, 2026 at 12:18:44AM +0100, Sam James wrote: > Eli Schwartz <[email protected]> writes: > > > On 4/17/26 6:30 AM, Matthias Ferdinand wrote: > >> Perhaps the message did not spread wide enough. Or are many Go programs > >> just not affected?
> 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. > > $ emerge @golang-rebuild > > ... > > fixing. It is regular like clockwork, so do people really need an > > invitation to do so? Personally, I am guilty of not compiling packages myself (except for some pkgsrc) and using mostly distributions in binary package form (Debian, Ubuntu, Alma). Also, many projects on github release binary packages. Doing a fresh release with no change except for the compiler used (and some new release version or build number) may make sense for those projects with affected binaries. > > 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.) Don't know enough Go to check affectedness of any project myself, but if it is that difficult it makes me worry even more :-) In the original advisory I did not see any mention if/how these issues propagate into compiled applications, and I only started worrying after reading the blog post about the memory safety issues and seeing that some projects had started issuing updates. A vulnerability in the build chain of course takes more time to assess and solve for all binaries in a binary distribution. Or you could just issue package updates for all Go applications (as proposed by Eli Schwarz). Not sure if I would really to want to see either every project/package using Go listed under the existing CVEs, or a new CVE issued for each just for increased visibility. I just wondered why the impact on binaries and binary packages is not being discussed more broadly (anywhere, not just oss-security). https://security-tracker.debian.org/tracker/CVE-2026-... only lists golang packages as affected, with some as already fixed and released, e.g. https://security-tracker.debian.org/tracker/CVE-2026-33810 (DNS contraints). https://ubuntu.com/security/CVE-2026-... are still showing "Needs evaluation" for the golang packages, but they contain a comment by Marc Deslauriers: "Packages built using golang need to be rebuilt once the vulnerability has been fixed." Alpine has bumped build numbers, as Chad Dougherty wrote here From: Chad Dougherty <[email protected]> Not an advisory, but Alpine did this: https://git.alpinelinux.org/aports/commit/?h=3.23-stable&id=f43ed43f4d329cb8cbca59b90c9560ab9e6d8f42 Alpine also had fresh releases on 2026-04-15, including some updates "rebuild with Go ..." Arch linux appears not to have recompiled Go applications (or at least not all of them, only checked restic) repo.almalinux.org does not show updated golang versions, so probably no recompiled Go applications either. Matthias
