Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 10:05 UTC (Tue) by epa (subscriber, #39769)
In reply to: Shared libraries by leromarinvit
Parent article: APT Rust requirement raises questions

Yes, that's the shameful secret of security updates in shared libraries. We've long mocked the Microsoft approach of rebooting the device for every change, but it's hard to beat if you want to guarantee that the vulnerable code is no longer running anywhere on the system.

In principle a program could be re-linked against the new shared library code while it stays running, but that requires an even stronger ABI stability guarantee than most libraries provide.

to post comments

Shared libraries

Posted Nov 25, 2025 11:26 UTC (Tue) by SLi (subscriber, #53131) [Link] (10 responses)

Hmm. Why is this a shared vs static library problem? Doesn't the application need to be restarted in either case to get the benefits?

Shared libraries

Posted Nov 25, 2025 14:02 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

The claim being made for shared libraries is that I can just update the library, and all the applications are immediately patched, which reduces admin effort as compared to static linking, where I have to update the binaries and then restart the applications.

The point is that it's not that big a reduction in effort - and it's a reduction in effort in the automated part, to boot.

Shared libraries

Posted Nov 25, 2025 14:59 UTC (Tue) by intelfx (subscriber, #130118) [Link] (8 responses)

> The claim being made for shared libraries is that I can just update the library, and all the applications are immediately patched, which reduces admin effort as compared to static linking, where I have to update the binaries and then restart the applications.

Nobody is making the claim for shared libraries to somehow obviate the need to *restart the applications*. You invented this claim out of thin air.

Shared libraries obviate the need to *update the binaries*, no more, no less.

Shared libraries

Posted Nov 25, 2025 15:12 UTC (Tue) by farnz (subscriber, #17727) [Link] (7 responses)

They don't even do that - you have to update the binaries that are supplied by the shared library, and the in-memory copies of the binaries, too.

The only thing they do is mean that you don't have to replace the executables - but replacing binaries (libraries or executables) is the bit of the update process that's simple to automate.

Shared libraries

Posted Nov 25, 2025 18:23 UTC (Tue) by intelfx (subscriber, #130118) [Link] (6 responses)

Clearly, "updating the binaries" in this argument means updating the _dependent_ binaries (the executables). I intended to include this clarification but omitted it due to sheer obviousness.

> but replacing binaries (libraries or executables) is the bit of the update process that's simple to automate.

It's not so simple (or cheap) to automate _creating_ those binaries in the first place. This is the part shared libraries help with: you do not need to rebuild and redistribute O(n) dependents when all you need is to make a compatible change in O(1) libraries.

Shared libraries

Posted Nov 25, 2025 19:14 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (5 responses)

> It's not so simple (or cheap) to automate _creating_ those binaries in the first place.

The argument made by the newer languages is that it should be. And they have largely succeeded. When is the last time you saw a Rust or Go project that *couldn't* be built with cargo build, go build, etc.?

Yes, yes, the subsequent packaging step is frequently more complicated. But that step is entirely the distro's invention. They don't get to make it everyone else's problem.

Shared libraries

Posted Nov 28, 2025 3:16 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (4 responses)

This full rebuild of applications however is a real problem for end users because they cannot choose anymore to only update the part that causes trouble. When application X has dependency Y and a full rebuild of X+Y has to be done to fix Y, most of the time it also comes with fixes (or even minor updates) of X, that users have to accept just to fix Y. This is a real problem because regressions do happen (frequently) and the more dependencies are involved in a rebuild, the more likely unintended changes are visible to the end user, who don't always have the choice of running the software that works for them and only update problematic dependencies.

Shared libraries

Posted Nov 28, 2025 5:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I keep reminding people here that Gentoo exists. And it's not a new fad, it's been around for more than two decades. And Nix is a newer example.

Shared libraries

Posted Nov 28, 2025 8:33 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

You mean they don't get a choice in the way they don't get a choice to keep the old version of a shared library (or indeed choose an arbitrary version of a shared library) for each of the other applications using that same library on the system that might not be affected by a fix?

Besides, updating all the dependencies to the same combination of dependency versions used by everyone else using the application actually reduces the number of truly different combinations in use, making it more likely that someone else is running the same version and has run into a bug before you do.

Shared libraries

Posted Jan 14, 2026 4:48 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (1 responses)

> You mean they don't get a choice in the way they don't get a choice to keep the old version of a shared library (or indeed choose an arbitrary version of a shared library) for each of the other applications using that same library on the system that might not be affected by a fix?

No I mean they don't have the choice to only updating the library without updating the application. The lifecycle of applications is not always the same as that of libraries. Take firefox as an example, you might experience issues caused by one of the thousand libs it depends on, but otherwise match your needs. By only updating that broken lib you get a perfectly functional browser. When using static builds, it's less likely that they'll rebuild your version based on an updated dependency so instead you're more likely to be forced to upgrade to the next version that probably doesn't please you at all anymore, or introduces new issues. The alternative is to not update the static application and that's an issue with security stuff (e.g. crypto libraries), which will overall degrade the security of what's effectively deployed in the field.

Shared libraries

Posted Jan 14, 2026 5:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

The corollary is that if you have a static version, it's usually easy to build a custom version, because the project will have tooling to easily manage the bundled libraries. Otherwise they'd go mad.

This absolutely applies to Rust and Go. I can make my own mini-fork within minutes for most of the projects, except for really hairy ones like Docker or K8s.

Shared libraries

Posted Dec 6, 2025 10:38 UTC (Sat) by jengelh (subscriber, #33263) [Link]

>We've long mocked the Microsoft approach of rebooting the device for every change, but it's hard to beat if you want to guarantee that the vulnerable code is no longer running anywhere on the system

The more evolved and hostile attached networks became between 1990 and now, the *less* Windows versions needed to reboot. So it does not seem like the mocking was ever done because of (in)security concerns.