The distro repositories are being continuously rebuilt, because packages are receiving continuous updates. In the meantime, as far as I'm concerned dynamic linking is itself a security failure, because if I run a binary I want to know exactly what code is being run, without having to worry about dynamic linking and loading nonsense inserting itself into my process.

> The distro repositories are being continuously rebuilt, because packages are receiving continuous updates.

At large timescales, yes. But not at timescales relevant for rapid security updates.

They aren’t being rebuilt with that kind of frequency as you might think.

They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference.

There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be).

Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library — static linking does not have the same means.

Statically linked programs don’t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do.

What is a security nightmare is statically linked binaries, you have no clue what they are linked against.

I'm against dlopen as well. If something makes use of LD_LIBRARY_PATH, rest assured that I want it excised from my system. Reproducibly-built, fully-static binaries are what I want, ideally with an accessible SBOM embedded.

So all your binaries are statically linked on your system? 100%?

That's the dream. I want a system that's 100% source-available, 100% reproducible, and 100% statically-defined. Nix looks like the closest thing to that right now.

I don’t see how Nix is close to your dream, Nix is just like any other system and links things like any other system.. I.e. mostly avoids static linking.

Debian did the strongest push for reproducible builds, and is 100% source available.

Do you know whether someone has made an estimate based on the history of actual vulnerabilities of how much rebuilding would need to be done in a non-shared library approach?

Not to my knowledge. But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc. If there is a bug in a shared library, one can replace it with a interm one very easily, and the whole operating system will use it. One can even replace it with a different implementation assuming ABI compatibility, without having to do "much".

Enclaves like Go, Rust, Swift (things that insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses.

Shrug :-)

> But consider something like crypto, libssl ... which is linked to almost everything, or libxz, zlib, etc.

AFAIK, the reason most Linux distributions have an allergic reaction to static linking is because of zlib. There was a vulnerability in zlib some time ago, and it required the distributions to find every single program which had its own copy of zlib (vendoring zlib used to be common back then), update these copies with the security fix (not necessarily trivial, since the vendored copy might be a customized variant of an older zlib release), and rebuild all these packages (which is a lot of "fun" when some of the packages are in a "failed to build from source" aka FTBFS state). The distributions learned their lesson back then.

The aversion to static linkage predates that, back many years static linkage also had other issues that have been solved today (ALSR ..). Many of the very basic points that Ulrich Drepper made some odd 20 years back (https://akkadia.org/drepper/no_static_linking.html) still hold.

For what it's worth, Rust uses libc by default in Linux.

On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait for the distro maintainers to get the update out.

That is a very, very tiny subset of things that are installed on any GNU or BSD system, and that need to get security fixes. Just recall the xz/sshd/system debacle, to patch your system all you needed was to replace libxz / libzma -- a DSO! This obviously ignores lots of other work -- but that work would have ballooned if standard practise was to statically link everything.

The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.

> then it doesn't have to wait for the distro maintainers

No, but it has to wait for each developer of each binary individually. Instead of relying on a team of maintainer, you now rely on all the developers.

"Self-update" isn't something magical: someone has to do build the new version and ship it. With static linking you still have to build and ship for every. single. binary. With dynamic linking you just build and ship the one library that everybody depends on.

Of course... and I'm not suggesting that every app in a linux distro should be as such. You can dynamically link with Rust, Go, etc. That said, for one of the 3-4 GUI apps that most people use, the distro process tends to leave people with relatively old versions missing critical bug fixes or features.

I tend to keep my host OS pretty bare, and most of my runtime apps in Flatpak and the stuff I'm working on in Docker.

> You can dynamically link with Rust

Do you have experience with that, or do you say it because you believe it's possible? Genuinely interested, because I have been looking into it and my conclusion was that it does not really do what I expect from "dynamic linking".

See e.g. https://news.ycombinator.com/item?id=40665343 and https://news.ycombinator.com/item?id=40661874

Go is the only one of the three that directly uses syscalls. Rust and Swift both go through libc. Swift never even had the option of directly using syscalls, since it was originally designed for MacOS, and syscalls are so unstable there that they've changed in minor version updates.

Most USERS only run a handful of applications any given month. I think upgrading 1-2 applications is easier to reason with over even a hundred packages.