>>>>> "Simon" == Simon Josefsson <si...@josefsson.org> writes:
Simon> Right, these are slightly different technical problems, but
Simon> as far as the brief discussion in the release notes --
Simon>
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking
Simon> -- I think the relevant aspect is identical: package X in
Simon> Debian contains an embedded copy of code whose corresponding
Simon> source code is in package Y in Debian, and fixing a security
Simon> problem in Y will require rebuilding X and the entire
Simon> dependency chain between X and Y that carry the code that
Simon> ends up in X.
That's what happens with static linking.
I think the vendoring situation is worse because rebuilding x and the
dependencies from x to y doesn't automatically pick up the fix.
So, while I agree with Bastian that you described vendoring and not
static linking, I think the key aspects of security support are *better*
for static linking than vendoring.
So, I'm not really sure why it's reasonable for you to be required to
come up with static linking examples from C.
Although examples of header-only c++ libraries or other libraries that
use significant inlining are easy to find.
