[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+V=+pu0DX8tKUxVEbsk8tL8TTVFF8A7DTbWUDCRywXLt0B6YQ@mail.gmail.com>
Date: Mon, 20 Apr 2026 13:59:35 +0100
From: Dimitri Ledkov <dimitri.ledkov@...inguard.dev>
To: oss-security@...ts.openwall.com
Subject: Re: Go 1.26.2 and Go 1.25.9 are released with 10
security fixes
Hi,
On Sun, Apr 19, 2026 at 10:14 PM Matthias Ferdinand
<ml.oss-security@...dv.net> wrote:
>
> [ hopefully, discussing binary releases is not off-topic ]
>
> On Sat, Apr 18, 2026 at 12:18:44AM +0100, Sam James wrote:
> > Eli Schwartz <eschwartz@...too.org> 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 <crd477@...oud.com>
> 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.
There are multiple opensource distributions that do choose to rebuild
all go binaries / applications / packages upon CVEs in the stdlib or
in any of the dependencies.
As an example (shameless plug) for Wolfi & Chainguard - one can see
over 400 builds for
https://images.chainguard.dev/security/CVE-2026-33810
It helps a lot to keep symbols tables in the binaries in general,
because then govulncheck on the runtime binaries can determine false
positives for the unused symbols - see demonstration of that in Build
Better Go release binaries at fosdem -
https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4406-build-better-go-release-binaries/.
In that presentation I have used coredns v1.11.1 which at the time
would show 15 vulnerabilities when symbols tables are stripped; and 8
vulnerabilities if symbols tables are preserved. The difference is
likely larger now.
I did not find similar granularity for CVEs in the stdlib - it would
be nice if govulncheck had symbol level information for the go stdlib
vulnerabilities; such that binaries that do not call particular
functions do not trip up the scanners; and can be auto-marked as false
positives; and thus not requiring rebuilds to pick up a newer
1.26.(n+1) in their build info metadata.
>From CVE scanning point of view symbols tables are nice, but they do
increase the binary size and thus runtime memory usage when the binary
is loaded / executed. I wish for detached symbols tables to be
supported, similar to detached debug symbols - but I have not checked
how to manually (with like patchelf) or automatically to produce that,
and if scanners would resolve and support loading detached symbols
tables. That would help providing these by default for scanners,
without the runtime memory usage impact.
The other thing is that likely there can be more agresive LTO
improvements, as currently go toolchain is concervative w.r.t. modules
and symbols linked; but given govulncher often says that a module and
symbol is imported but not used - it seems that there could be less
things linked into the binaries in the first place, reducing CVEs. An
extreme case was removing a single unused file in a dependency which
wasn't called or used at all
https://github.com/opencontainers/runc/pull/5056 (merged and
backported via other prs, based on discussions there) resulting in a
6.7% decrease in the runc binary size.
Fewer symbols linked in binaries, and symbol level CVEs for stdlib
would greatly improve go CVE management and reduce the need to mass
rebuild everything.
Regards,
Dimitri.
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.
