Static linking is dead. Most applications cannot be built statically, at all.
Solaris-style RPath is still an option on Linux, but it is rarely used.
As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible.
Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner.
This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.
Golang doesn't really support static binaries. This may be confusing, since it compiles-in all golang dependencies, but by default, all output is dynamic, and it's quite difficult to get static binaries out of it at all.
The golang model expects all golang deps to be distributed as source code, and then it expects to dynamically link to all C dependencies. It is technically possible to diverge from the latter set of expectations, but it is not easily or commonly done.
C++ is much like golang in that respect. Template libraries are always "static" in the sense that they are distributed only as source code, but the final binary output is almost always a dynamically linked binary.
The question about it comes up every so often, but nobody has ever put up the effort to maintain it. It appears to be a lot of work for very little gain.
Certain libs use dlopen() which needs dynamic linking. Mesa, Pam, Qt (static is possible but a lot of stuff will break), Glibc(static is possible but nsswitch.conf will break), Alsa. So most graphical apps will fail to be pure static(Prob possible but will hardware/config specific). So we need to tackle and provide alternatives to dlopen.
Running NSS and PAM modules in-process was IMO a historical mistake. Convenient in one aspect, rather inconvenient and impractical in many others.
If we were to redo these today, I think we'd do them out-of-process and talk to them over UNIX domain sockets or pipes.
The transitive dependencies of NSS and PAM modules can also wreak havoc with your application. There are many bugs which have arisen because of these limitations. Yes, looking at you, GnuTLS.
OpenBSD chose BSD Auth over PAM for this reason. With BSD Auth the C API invokes binaries in /usr/lib/auth which are SUID or SGID according to which permissions are required for the credential store.
Well, not sure about C (but I assume something using gtk could be pain), but if we expand that to C++, I mean, I would expect firefox and chrome to be basically unbuildable in static manner.
> no matter how hard you try
Well, no. If you are willing to rewrite it (even significant changes), of course it will be possible to built it statically. That does not mean it is doable in practice.
I doubt they meant "no matter how hard you try" nor were limiting this to C programs only. Something the size of Firefox, for example, with hundreds of files, multiple languages and dozens of platform variations, is simply not designed for a fully static build and trying to modify it to build like that would be an absurd amount of work for basically no reason, so it hasn't been done and probably never will be.
Add licensing complications to that (Qt is notorious for this) and OP's statement is for all intents and purposes true.
Perhaps so, but Firefox is but one program among the hundreds or thousands that are available in a typical Linux distribution. "Most" implies a quantitative analysis (i.e., more than half), which I think is disputable.
Static linking is an atavism. Application authors don't spend time thinking about it any more.
The main reason static linking persisted as A Thing into the 1990s was that fossilized vendor UNIXes didn't support it, or didn't support it well. Those systems are all extinct.
About the only place you still see static linking is embedded. And that is its own world.
The two weaknesses cited by the OP to support your argument were CVE-2019-17498 and CVE-2020-12284. That means if you use the RedHat's App Store to illegally torrent media content and pentest strange ssh servers, you might get pwnd. Tears are flowing to mine eyes.
Solaris-style RPath is still an option on Linux, but it is rarely used.
As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible.
Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner.
This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.