Shared libraries [LWN.net]

Shared libraries

Posted Dec 6, 2025 21:48 UTC (Sat) by johill (subscriber, #25196)
In reply to: Shared libraries by farnz
Parent article: APT Rust requirement raises questions

On the flip side, when a distro chooses to have a single libtiff/ffmpeg/whatever build installed at a time, it could actually give users a better choice. Default to libtiff-simple, but let a user install libtiff-everything, and both provide a virtual libtiff package. Now all software can either do "ThunderScan RLE encoding" or not, depending on which libtiff you installed, and you don't even need to rebuild the software if you do have such a special case. (Though obviously the problem with this is making it discoverable.)

Which is basically the "multiple builds", but as long as you don't need to do "internet facing server" and "legacy media" on the same machine, it'd be much simpler.

(You could argue that maybe a web browser should have a restricted version and the local viewer not, but realistically you might even need the browser to have the full version if you're working with such files since you might have a web-based organisation tool etc., so I don't think that really works)

to post comments

Shared libraries

Posted Dec 8, 2025 9:28 UTC (Mon) by farnz (subscriber, #17727) [Link] (5 responses)

The trouble with that is that what you want is not "simple" and "everything", but a variety of different choices: there's faxes, medical imaging, scanned paperwork, prepress artwork and more, to name some common use cases for TIFFs.

In the extreme, you end up with a different libtiff for each use case, and you want them to be parallel installed and each only used by one program on a system - e.g. the fax handler has the fax subset (and doesn't have any others), while the paper document archive program supports the subsets used by faxes and scanned paperwork, but not medical imaging or prepress artwork.

And once you get there, where's the advantage of dynamic linking?

Shared libraries

Posted Dec 24, 2025 14:49 UTC (Wed) by sammythesnake (guest, #17693) [Link] (4 responses)

If there's a need for that kind of thing, then a plugin mechanism is the real answer - nothing to do with static linking or otherwise...

Shared libraries

Posted Dec 24, 2025 17:31 UTC (Wed) by farnz (subscriber, #17727) [Link] (3 responses)

A plugin mechanism doesn't help - it just rearranges the deckchairs.

Let's switch to video formats, and use GStreamer, which has a plugin mechanism. How does my "upload a video from your phone via the Internet" program know that a given plugin is not for it to use? In the upstream version, it's fine - they just don't install vulnerable plugins, so by definition, all plugins are fine for it to use.

But the distribution has a problem: a phone will never record in (say) LucasArts SANM format, but other software installed by the user might well have a legitimate reason to want the GStreamer plugin for LucasArts SANM to be available and working. Equally, though, the program might well benefit from you adding an AV2 plugin (so that phones that record AV2 video instead of HEVC are supported), even though it doesn't know about AV2.

This, however, is the same problem as before, just rearranged - you need parallel installable "profiles" of the library (in this case GStreamer), such that each program gets the profile it wants. And in the extreme, each program has its own profile.

Shared libraries

Posted Dec 24, 2025 18:22 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> This, however, is the same problem as before, just rearranged - you need parallel installable "profiles" of the library (in this case GStreamer), such that each program gets the profile it wants. And in the extreme, each program has its own profile.

So `/etc/pam.d`-like files but for plugins then? Sounds like fun ;) .

Shared libraries

Posted Dec 24, 2025 18:56 UTC (Wed) by excors (subscriber, #95769) [Link] (1 responses)

That sounds like a pretty easy problem to solve: the application can have an allowlist of plugins. When a significant new codec like AV2 is released, maybe a couple of times per decade, the developers can add it to the list. Maybe have a config file so users of old releases can add it without upgrading. This should only be needed for applications that are processing untrusted input on systems where they can't trust the administrator not to install insecure plugins, so it's going to be end-user things like web browsers that have to be constantly upgraded for security reasons anyway and it's minimal extra effort to maintain the plugin list.

(GStreamer already splits plugins into "good" (safe to use), "ugly" (good quality code but copyright/patent licensing issues), and "bad" (unsupported; maybe low quality, unmaintained, rarely used, etc), with separate Linux packages for each set, plus a number of single-plugin packages (for licensing or dependency reasons). On systems with a responsible administrator, that means you can already choose what profile of plugins are available, and there's no technical reason it couldn't be more fine-grained.)

Shared libraries

Posted Dec 25, 2025 19:14 UTC (Thu) by farnz (subscriber, #17727) [Link]

But this is the same mess as multiple shared libraries, just moved around - it's not actually a solution if you want to have all programs use a unified feature set, which is an explicit goal of how the distro mechanism works (see the earlier comment from dvdeug).

And that's the root of the problem I'm raising. There exist cases where unifying features introduces a vulnerability - indeed, the allowlist mechanism you're described also introduces one if an insecure plugin is added that upstream explicitly don't support because they know it opens a security hole in their software. As a consequence, turning a simple "statically link ffmpeg, configured just for the plugins upstream has reviewed and know are good" into "port to a plugin architecture, maintain allowlists, somehow ensure that downstream never adds something insecure to the allowlist" problem, which is a lot of extra complexity, and all so that downstream can "unify" features for things that don't benefit from the unification (since the allowlist promptly bans use of all the extra features so enabled).

This is the flip-side of distros spotting problems as they package - because they change things (they're effectively a friendly fork of upstream), they run the risk of introducing new bugs. It is not nearly as simple as "static linking bad, dynamic linking good"; it can also be "by unifying features, I've introduced a bug that does not exist upstream, because I de-vendored a library, linked to the shared version, and now we have problems".