Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 15:18 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Shared libraries by paulj
Parent article: APT Rust requirement raises questions

Oh yes - both ways round are possible.

Note that the distro is quite capable of using the dependency information it already has (BuildRequires and the like) to rebuild statically linked binaries - dynamically linked versus statically linked is more about how much automated work has to be done to get you a fixed version in place, rather than about which is "more secure".

And I don't believe anyone has done the study to determine which is actually more secure in practice - static linked executables, with unused parts of libraries turned off, or dynamically linked executables sharing a library with more used components. Once you allow for things like time to determine that an update is needed, it's quite a complex space to think about, and (like so much in computing), we're more going on "what feels right" than on hard data.

to post comments

Shared libraries

Posted Nov 25, 2025 17:42 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

My point was that, even IF distros were not great at updating the shared library, i.e. just average, it would still result in the system applications generally ALL being 'fixed' in an average and bounded amount of time - if they use shared libraries. Whereas, with apps statically linking, assuming a decent number of app, you will have a much longer and unbounded period of time where you have apps installed with a security problem.

I don't see any reason why app would or would not choose more locked-down build options than the distro. Assume that varies randomly across apps, and assume it varies randomly with libraries. The point still stands: The 'average' Linux distro gives you a bounded, shorter window of time where you have vulnerable apps from a bad library.

Shared libraries

Posted Nov 26, 2025 8:51 UTC (Wed) by taladar (subscriber, #68407) [Link]

This is not quite true. If the shared library solution works there is a strong chance that rebuilding the unmodified binary will work too so the distro could also do that, the builds might take a bit more CPU-time but overall this is definitely also bounded.

If, on the other hand, the binary needs to be modified to support the fixed library version there is a strong chance there is no ABI-compatibility for the shared library to take advantage of anyway.

Shared libraries

Posted Nov 25, 2025 17:56 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (11 responses)

> Note that the distro is quite capable of using the dependency information it already has (BuildRequires and the like) to rebuild statically linked binaries

That’s a workaround not a feature, it transforms updates in mass rebuilds, that require a lot more build power, and add an economic barrier to entry to the distribution game (not that the big distributors will complain much about this part).

Nevertheless the real major drawback of static building is that it removes any developer incentive to converge on specific component versions. With dynamic building you have to choose one of the handful of versions packaged by your distributors. With static building there is no reason to make the effort (which is why developers are in deep love with static building).

The consequence of this lack of version convergence, is that static building is not only massively more wasteful on building power, it is massively more demanding in maintainer power. You need to tailor security patches (and security impact analysis) to each and every component version individual developers chose to vendor in their static build. In effect you promote technical debt (increase short term benefits at the expense of long term maintenance).

The problem does not exist FAANG side, because FAANGs force their dev teams to use the same golden versions. Guess how promoters of static building would welcome a distribution, that told them “you can use static building, but only with the following vendored versions, because we do not have the resources to patch others”.

Shared libraries

Posted Nov 25, 2025 18:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> That’s a workaround not a feature, it transforms updates in mass rebuilds, that require a lot more build power, and add an economic barrier to entry to the distribution game (not that the big distributors will complain much about this part).

Eh, no. Unless you're targeting something like m68k, rebuilding is cheap. We can use Gentoo as an example, rebuilding the world takes about 12 hours on a reasonably fast computer. And this is for a catastrophic bug, where everything needs to be updated.

In most cases, you're looking at maybe a handful of packages.

Shared libraries

Posted Nov 26, 2025 8:54 UTC (Wed) by taladar (subscriber, #68407) [Link] (4 responses)

On the other hand why is converging on a version that isn't the latest version a good thing? Shared library distro builds are essentially always stuck on the oldest version that some reverse dependency requires while static linking can just use the latest version, becoming part of the much, much larger group of people who aren't years behind.

This gets rid of all the effort required for distro specific bugs when developers don't want bug reports for ancient versions, all the backporting,...

Shared libraries

Posted Nov 28, 2025 9:37 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (1 responses)

The latest version is not necessarily reliable, give the developers of other components a break, they also need to explore new approaches. Converging on a common version means a lot of people found this particular version reliable;

Static building is the opposite of using the latest version, people use the latest version *at the time they bother to check* and then lock it down and accumulate technical debt. People do not like making the effort to update, period, they can’t complain using dynamic libraries forces them to update on a regular cadence (that would expose that they do not want to make this effort) they complain that the update forced on them by distributions is not new and shiny enough.

Shared libraries

Posted Nov 29, 2025 16:20 UTC (Sat) by khim (subscriber, #9252) [Link]

> Converging on a common version means a lot of people found this particular version reliable;

That's only true for forges like PyPi or crates.io. Where people are free to pick any version they like.

With distros is the exact opposite: few packagers, often just one, single, person decides what version of library to package.

That's the opposite of the process that may lead to the outcome you describe.

> Static building is the opposite of using the latest version, people use the latest version *at the time they bother to check*

Still better than some random version that was picked by god-know-who for god-know-what reason and which wasn't even tested in conjunction with app.

> they complain that the update forced on them by distributions is not new and shiny enough.

People complain when something doesn't work, period. It may be too new or too old or anything in between.

But with distros they are often in position that they have no one to even complain to because person that assembled the crazy combination of libraries that breaks things is not even result of conscious decision, but more of result of random dice throwing.

According to the distro makers every package should be ready to work with every version of library… but that's rarely a thing that any sane developer would accept: to know whether something works or not you need to test… and distro makers make that exceedingly difficult.

Shared libraries

Posted Nov 28, 2025 11:25 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Shared library distro builds are essentially always stuck on the oldest version that some reverse dependency requires while static linking can just use the latest version, becoming part of the much, much larger group of people who aren't years behind.

Yeah, that's just the exact opposite of how it happens in reality.

In reality, applications in ecosystems with vendor-controlled static linking/bundling/vendoring get locked to the first version of each dependency that happens to work and never upgraded again (until a vulnerability is exploited in the wild, or until maintenance of a suitably obsolete build environment becomes untenable through actions of others).

Maintainers of distributions, on the other hand, care about health of the overall "ecosystem" Of course, the quality of said care may differ, but the overall concept is always there. You, as a user, may be briefly stuck on non-latest versions (or even on legacy branches) of some dependencies, but the entire distribution moves forward as fast as manpower allows.

Shared libraries

Posted Dec 1, 2025 9:59 UTC (Mon) by taladar (subscriber, #68407) [Link]

That is the way it works in C/C++ when they vendor dependencies because the tooling to upgrade sucks but e.g. on Rust, when upgrading dependencies is as simple as running cargo upgrade and cargo update and then fixing the minor compile issues 99% of the time (i.e. every time some dependency didn't completely revamp their API which is very rare) keeping up with dependency versions is incredibly easy.

Shared libraries

Posted Nov 26, 2025 9:22 UTC (Wed) by taladar (subscriber, #68407) [Link]

If rebuilding thousands of packages was such a big deal, why can the Rust project easily do https://rustc-dev-guide.rust-lang.org/tests/crater.html runs regularly to test if the compiler breaks any crate on crates.io?

ABI stability can block security updates

Posted Nov 27, 2025 18:14 UTC (Thu) by DemiMarie (subscriber, #164188) [Link] (3 responses)

Static linking allows security updates to libraries to be applied to applications that are ready for them, even when other applications are stuck on vulnerable versions. See gRPC in Fedora.

ABI stability can block security updates

Posted Dec 1, 2025 9:17 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

Unfortunately baddies do not care if you have double plated the main door with the latest uber-expensive alloy, if the service door right next still uses rotting medium (a very common situation in proprietary setups).

What matters for security is that *every* deployed software bit uses fully patched components, even when those components are slightly old because no security event required their update and a full OS update is expensive effort-wise.

Static linking as you wrote promotes fixing highly visible main doors while keeping service doors wide open.

ABI stability can block security updates

Posted Dec 1, 2025 10:50 UTC (Mon) by taladar (subscriber, #68407) [Link]

You are completely ignoring that dynamic linking keeps the entire distro on an old version (or rather often a new, completely untested version somehow considered stable because it is called a "backported fix") because the many less popular programs that most systems don't even install have not been updated yet.

ABI stability can block security updates

Posted Dec 1, 2025 10:59 UTC (Mon) by muase (subscriber, #178466) [Link]

But that’s not true, as different components have different attack surfaces. gRPC is a good example, because it’s a huge difference if you have a public service that works with untrusted gRPC messages from the outside, or if your coordinator just uses a fixed set of gRPC messages to distribute your physics simulation across multiple worker processes via stdin/stdout on your own desktop.

In the first case, that’s a real-world RCE, in the second case you probably cannot even exploit the bug because you can’t control the input in the first place (messages are generated by the coordinator, not you).

Different use cases have different attack scenarios and different attack surfaces. There are tons of applications where a gRPC vulnerability will be a serious incident; but there are also a lot of cases where it – realistically speaking – it’s simply not exploitable.

Ideally, you should fix all bugs asap – but given the limited resources IRL, it sometimes is simply necessary to triage. That includes that if you cannot fix all packages at once, you can at least try to fix those where the bug has the most impact; i.e. users*impact (“reduce the bleeding”). It simply does not make sense to hold a fix back for the majority of users because you’re blocked by some obscure package nobody is using, or to wait for a package where the bug has no relevant real-world impact.