Shared libraries [LWN.net]

Shared libraries

Posted Dec 5, 2025 21:49 UTC (Fri) by dvdeug (subscriber, #10998)
In reply to: Shared libraries by farnz
Parent article: APT Rust requirement raises questions

> In the scenario I outlined, you'd read the TIFF with the software that knows about legacy Mac formats, and convert it a modern TIFF in the process

There's a lot of times the solution is set VXTMLR=1 and it just works. A fact you learn six weeks after you finish redesigning the whole system with new software and custom code, or replaced a piece of hardware. You have a TIFF file that is read by TIFF reading programs; the fact that it's not being read here will frustrate all non-technical users and many technical ones. Then you get the tech in, and they realize it's running libtiff like the rest of the system, so why isn't this working?

> And I chose that format very, very deliberately

And I stand by my case; not supporting certain files in a format because you don't think they're being used is a recipe for pain and annoyance. I'll go further and point out that the gain for disabling this is tiny; if you don't trust libtiff, then you should protect yourself in some way, not just disable one or two compression schemes that you don't feel are being used that have a tiny chance of being the angle someone uses to attack libtiff. TIFF, like various media schemes, is a format you'll never support all files in the wild, but you should either support some narrowly and clearly defined subset, or support everything that e.g. libtiff/ffmpeg does. Or don't support it at all, which means people know to run a different tool or convert it to a format you support.

I'm also not convinced that everyone will be so careful as you. It's easy to get carried away; most attempts at making an X clone with only the features that people really use fail because while people only use 20% of the functionality, they all use a different 20%.

to post comments

Shared libraries

Posted Dec 6, 2025 21:24 UTC (Sat) by farnz (subscriber, #17727) [Link] (11 responses)

Most of the time, TIFF reading programs don't support ThunderScan RLE encoding. That's a big part of why I chose it - it's rarely supported unless you've deliberately enabled it, and you only need it if you're dealing with deeply legacy media.

I could, of course, have chosen Internet-facing streaming media software that uses its own build of ffmpeg in the upstream configuration, where only the formats that are expected to work are enabled, but where the distro has turned on support for all the weird and wonderful formats that ffmpeg supports.

In both cases, though, your argument is that it's important to introduce security issues into software whose upstreams don't have that issue because they run with cut-down dependencies, because there might be a rare user who actually wants to deal with ThunderScan RLE TIFF files, or upload LucasArts SANM videos for transcoding to AV1 for streaming, or otherwise do something deeply niche and weird. I would suggest that actually, what you want is more than one build of libtiff, or ffmpeg, or other functionality, where the local-only media player can decode LucasArts SANM, or the legacy 68k Mac (ThunderScan was not supported on PPC Macs) file reader can convert your scanned documents to a modern format, but the Internet-exposed one doesn't have the extra codec support by default, precisely because of the security risk.

Shared libraries

Posted Dec 6, 2025 21:48 UTC (Sat) by johill (subscriber, #25196) [Link] (6 responses)

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)

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".

Shared libraries

Posted Dec 7, 2025 8:56 UTC (Sun) by dvdeug (subscriber, #10998) [Link] (3 responses)

> your argument is that it's important to introduce security issues into software whose upstreams don't have that issue because they run with cut-down dependencies, because there might be a rare user who actually wants to deal with ThunderScan RLE TIFF files, or upload LucasArts SANM videos for transcoding to AV1 for streaming, or otherwise do something deeply niche and weird.

My argument is that first, you aren't gaining much by stripping features because they're rare. Either you trust libtiff, or you don't. FFMPEG has more dependencies and sometimes more sketchy dependencies, so that's slightly different. But in either of those cases, you're taking a small chunk of code in a much, much bigger library, and treating it as a security win to disable it, not because it's known to have anything wrong with it, but just because you can. Don't; if you don't trust libtiff, sandbox it. If you find libtiff trustworthy enough, you're not gaining anything measurable by disabling random tiny parts of it.

Two, to you, a ThunderScan RLE TIFF file is an obscure Macintosh format. To a user, it's a TIFF file, a relatively common format. If I try and use an .snm file in a tool that plays movies, and it doesn't work, I look for a tool that supports .snm files. If I try and use a valid .png file in a tool that supports PNG files, and it doesn't work, I'm going to treat that tool as broken. I've read the TIFF standard, and understand how complete support is impossible, but the user is going to treat that as the PNG case, not the SNM case.

Third, I think this is a slippery slope that would make software less pleasant to use. ThunderScan RLE is a rare format, yes. But as I said, it's a small chunk of code, so what else are you going to take out? I have 16000 TIFF files on my hard drive, and most of them are in CCITT Group 4 fax encoding, which is not in the TIFF baseline. They may be few, but I have 2, 3 and 4 respectively in PackBits (baseline, but considered rare on Wikipedia), Deflate (PKZIP) (obsolete, uncommon), and LZW (not in baseline, and who uses LZW any more?). Having to spend any time to figure out why the program that views TIFF files doesn't view these is a waste of my time, and for many users, that could be a waste of hours and possibly expensive bills to call in a technician.

> I would suggest that actually, what you want is more than one build of libtiff, or ffmpeg, or other functionality,

No; I want something that processes TIFF files to actually process all TIFF files. That's not realistic, but approaching it is still important for the quality of user experience. If you don't trust libtiff, I expect you to not just disable a couple of minor compression schemes and call it done; you should protect the program from libtiff bugs. ffmpeg is a gnarlier mess, but I suspect there's even less real data about what video codecs people are using, and probably even more reason to sandbox it instead of trying to figure out which codecs are unused and blindly trusting the rest.

Shared libraries

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

Just to be clear, then: you want a fax handling program to have extra vulnerabilities over and above upstream, because it's possible that someone might want to reuse a fax handling program for legacy Macintosh scans.

There is no program out there that supports all TIFF files - libtiff certainly doesn't.

And coming back round to my initial point: by adding in the extra file format support to someone's fax handler, the distro has introduced a vulnerability that is not present upstream, and where upstream is quite likely to say "well, why did you add ThunderScan RLE decoding to my fax program? That makes no sense at all, since faxes are 1 bit (by definition), and ThunderScan RLE is 4 bit (by definition)". This is not a win for users, or for the upstream, and it's a security hole opened by the distro insisting that there is a shared libtiff.

Shared libraries

Posted Dec 8, 2025 11:16 UTC (Mon) by dvdeug (subscriber, #10998) [Link] (1 responses)

>Just to be clear, then: you want a fax handling program

Just to be clear, the idea that this was a fax handling program is present nowhere else in this discussion. At no point did you offer a reason ThunderScan RLE wouldn't be supported besides "it's rare".

> There is no program out there that supports all TIFF files - libtiff certainly doesn't.

There's no program out there that supports all C++ files; g++ certainly doesn't. Is that argument going to pacify you when it fails on your C++ file? I'm asking programs that claim to support TIFF files to try their best at supporting TIFF files, and not put extra work into disabling support for certain TIFF files.

>And coming back round to my initial point: by adding in the extra file format support to someone's fax handler, the distro has introduced a vulnerability that is not present upstream, and where upstream is quite likely to say "well, why did you add ThunderScan RLE decoding to my fax program? That makes no sense at all, since faxes are 1 bit (by definition), and ThunderScan RLE is 4 bit (by definition)". This is not a win for users, or for the upstream, and it's a security hole opened by the distro insisting that there is a shared libtiff.

No, the distro has not introduced a vulnerability that is not present upstream. It may have introduced a vulnerability, and the probability it did so is key to judging whether or the action should be taken. Again, it is a win for users to have as much support for their files as possible, and this idea that the program wouldn't accept ThunderScan RLE anyway is something new. The very fact that it only supports 1 bit files means that it should bail out of reading the file long before any ThunderScan RLE specific code is run.

It's possible that just adding the support code will close a vulnerability; mishandling of an error state was what destroyed the first Ariane 5, one of the most expensive software errors ever, after all. The log4j problems, similarly, came from issuing errors to a log file and could have been blocked in some cases by just changing which error message was logged.

More importantly, by linking the program to the shared libtiff, it avoids any vulnerabilities that could come from the window between the shared libtiff being fixed and the program being fixed. That's why distros demand that programs be linked to shared libraries instead of vendored ones, so security holes in the library get quickly patched on being fixed, instead of fixed in every copy on the system individually.

Even in the fax case, it's not as simple as the distro introducing a vulnerability; the distro could be patching a vulnerability just by making the change, and they could be minimizing the time that an openly known vulnerability exists in the program. Even if the user support is irrelevant, how likely a vulnerability is to be created by a change and how likely it is to be fixed by a change is important.

Shared libraries

Posted Dec 8, 2025 11:25 UTC (Mon) by farnz (subscriber, #17727) [Link]

You made assumptions about what the program might be, and asserted that a bug introduced by ThunderScan RLE support would be worth having for the extra supported formats; I've introduced a bit more information, explaining why ThunderScan RLE support is not worth having.

And just to be completely and utterly clear: you are saying that a vulnerability that is not present in the upstream version of the project, or in their binary builds, but is only present in the distro build (where they've unbundled libtiff and linked a version that has a security issue that can be triggered just by loading a TIFF file) is not introduced by the distro?

And my argument is that the distro is not always fixing things by unbundling dependencies and unifying on a single version - it can be both fixing some problems and introducing new ones. Which tradeoff is better is not backed (in either direction) by data.