Technology moves so fast that everyone has short memory, patience and attention span.

So stuff like this happens [this is a tongue in cheek scenario, treat it as joke, not criticism of particular people or framework]:

Developer1: "Argh, I can't figure out dependencies for this library",

Then someone comes along and "fixes" it:

Developer2: "Look, just static compile it / include all deps in a subdir some place. See, fixed! I even made a language / framework thingie to do this for you. Yeah, those stupid old packagers and OS people made such a mess...".

Developer1: "Oh wow so easy, I'll be using this and tell others to use it too." /goes to twitter...

A few years later, everyone uses the new shiny dependency-bundling library/framework thingie. Then a security vulnerabily hits and everyone realizes why those old boring packagers and OS people set things up the way they did. 6 days later everyone forgets and jump on the next new shiny framework. Cycle repeats...

Containerization might well be the solution to this kind of problem: libpng's vulnerabilities no longer matter much if you've isolated it into its own VM with no access to resources beyond the ones it needs to decode a PNG into a pixel buffer. I've been working on a little OS project along these lines, where every process runs in its own VM, and every shared service is provided by a local server. There's no dynamic linking. Instead of dealing with the cost of constantly churning code, and all the instability and unreliability that comes along with it, the idea is to pay for security up front by isolating everything. If you want to decode a PNG you have to spin up a VM, stream the PNG data in, and stream the decoded pixels out. The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory. If it crashes, it crashes, and from the client's perspective the app just exited with a non-zero error code.

> The PNG decoder has no access to the file system, network interfaces, user interfaces, or really anything but stdin and stdout and some memory.

So you've rediscovered what UNIX has allowed us to do for decades now.

Things like process isolation, memory isolation, file isolation, and hardware isolation aren't new. UNIX systems offered mature implementations of them in the 1980s, if not before then.

Best of all, this functionality was offered without needing to resort to resource-intensive virtual machines or anything of that sort.

Those who want the level of isolation you propose have been able to get it for a long time now. They just tend not to, because it's inconvenient and impractical for real world systems.

That's just not true. A program needs to be started root to execute setuid(2): there is no way for a program started by an unprivileged user to drop privileges. Nor can it drop network privileges. That's why tools like pledge(2) and seccomp had to be added, but they have their own problems. To get the level of isolation GP described, you need some fairly esoteric solutions.

Well seccomp() strict mode (only allows read, write, exit) has been available since linux-2.6.12 (2005). So no need to invent something new, or set up a bunch of cgroups and namespaces, to get processes that can only read stdin and write stdout and use some of their own memory.

Oh, sure, but once you start playing "there's nothing new under the sun", the mainframe guys will eventually come along and explain how they were doing all that in some vastly more sophisticated way back in 1962 using systems none of us have ever heard of. So what? I don't care. I just think that the definition of "practical" is shifting, and I want to play with another way of doing things in case it turns out to suit my needs better.

For something like libpng, there isn't any "instability and unreliability" and the code is hardly churning. Just `apt-get update` or `pacman -Syu` and you've got the patched version, compatible with all binaries on your system.

The only exception would be something like Chrome/Chromium that bundles a bunch of its own tweaked copies of common libraries. Or various closed-source software not controlled by your package manager, like some commercial games which have a linux build available. But many systems, like my home router/fileserver, and my workstation, don't have any of these exceptions, and they were updated in about 2 minutes. (I have no long running network daemons using libpng, but if I did they would be easy to restart.)

We have no processors which can efficiently isolate memory spaces with that fine granularity.

Which is why we should have stopped using C long ago and used languages which could guarantee that kind of isolation with less overhead.

Sounds like Qubes

I'm a gentoo user and before preserved libs came in, updates to libpng required recompilation of almost everything on a system. So while libpng is unknown to most linux users, gentoo peeps are well aware of it.

Anyway, this is exactly the question I wanted to ask, whether stuff like this counts against bundling. I am, however, not very experienced in these things, I'm curious if anyone else who has more experience with distribution of software could weigh in on whether there is a way to mitigate this issue when it comes to people who choose to bundle software for ease for users' sake.

Any sane library should be using a stable ABI. Qt does it with giant libraries but any software compiled against any 5.x release will work with any of them since they require ABI stability. You don't even need to ABI break on new features if you use PIMPL right. Its only when you change your API function signatures that already exist that you break the ABI. And thats the way every library should be.

Most libraries are not sane. API breaks are common, and often security updates are only available in new, incompatible releases.

Then don't use those libraries! How can you trust a third party library to provide functionality to your software if they cannot even release sanely with ABI stability? Its a disservice to you and your users to risk security vulnerabilities like this.

with tons of functionality there is no realistic alternative.

Simplify the interface. Don't combine unrelated functionality in a single library.

PIMPL is an inefficient antipattern when the holder object is itself heap-allocated. You're better off coding against interfaces, COM-style.

It doesn't matter if your holder is heap or stack allocated, the d pointer is always heap allocated and the only reference to it is the private internal. With interfaces you either have an awful dummy static constructor for your private object somewhere or you have a non-virtual parent class with dummy implementations of all its functions and a mangled constructor that produces its private child.

For the developer, interfaces are cleaner, but for users, the interface style is leaky where PIMPL is not. That makes it superior. It also avoids overriding the intent of inheritance as a way of achieving ABI compatibility when it already has a significant and intentional function of runtime polymorphism, and can easily confuse users as to whether the implementation is to preserve the ABI or provide multiple implementations in the same release.

Right, so if your holder object is heap-allocated, you need to dereference a pointer so that you can then call into the implementation. That's inefficient, bad for the cache, and puts needless pressure on the heap allocator. C++ classes built out of pure virtual member functions are just as compatible. If you use something COM-like, you can reference-count and manage them in a uniform way.

PIMPL as commonly described is a waste of good electricity, like most design patterns. Especially because most of the time I see it used, it's from the keyboard of some well-meaning but inexperienced developer who doesn't even need to maintain binary compatibility.

> I'm a gentoo user and before preserved libs came in, updates to libpng required recompilation of almost everything on a system.

I'm also a Gentoo user. (Hi! :D )

ISTR that preserved-libs "just" lets you delay recompilation of affected packages [0] by keeping the old libs around until everything that needs rebuilding to link against the new version has been rebuilt. You still need to rebuild packages. Am I wrong about that?

[0] Or, -alternatively- "just" lets you keep your system working while you rebuild affected packages.

Oh man, the number of times I have delayed updating a system because different programs required different versions of libpng. On the other hand, having used gentoo as my primary distro for nearly a decade I have found that there are some serious benefits to actually knowing what libs are actually involved in creating a functional linux environment.

No that's exactly right. I'm specifically referring to your [0] comment. It allows me to spread the compilation over a longer time (days) while being able to use the old things without breakage. Before, I had to recompile everything and things would be unworkable until everything was recompiled. I now have a number of boxes with distcc so compilation times aren't that bad nowadays. But back in 2010 or so, when I just had a shitty gateway laptop, dealing with libpng version bumps was a weekend affair.

> Before, I had to recompile everything and things would be unworkable until everything was recompiled.

Oh god, tell me about it. I was around for the first libpng upgrade catastrophe, way back when. Portage/emerge has gotten so much better since then. :D

The problem is that it only works with system libraries and when you have a central software repository. You couldn't even do it with an appstore, as you can possibly break tons of software that you can't patch yourself. So what actually happens with dynamic linking there is that old .dll/.dylib files (with vulnerabilities) get copied around.

With zlib I agree though. Static linking doesn't make sense with such a standard library, at least under unix systems.

So do a mix? Make system libs shared and apps bundled when they are needed? Can't the app store work like your package manager anyway? Speaking from ignorance here, I want to know if it's possible.

The Click-n-Run app store from LindowsOS back in 2002 was based on apt and dpkg. So yes, it is possible, especially if there are automated tests that can tell when a dependency update breaks something.

Static linking may be bad for security but good for saving hours of frustration. It's a trade-off and it's not clear that security is automatically the most important thing always.

Just look at any forum about some open source software. There'll usually be endless posts from people complaining that they can't compile it because of some weird dependency errors. These are really widespread and time-wasting problems.

Unnecessary dependencies are a bug. I've seen people pull in half a dozen nested libraries just to avoid writing ten lines of code. Sometimes re-inventing the wheel is the right thing to do.

If a software use libpng to read images that only come from installation directory, I don't think it's really a problem to link statically libpng.

For example a GUI that loads icons, background images, button images etc.

A system can be owned using various exploits combined together. So if someone finds a way to alter the installation images, suddenly a mild trick that would normally just result in funny icons is now an exploit.

Kinda good example right here: https://www.youtube.com/watch?v=CkPAgv1Gjz0

Maybe Nintendo never considered someone screwing around with their network to load an arbitrary image in a place that only Nintendo-Generated Mii png images should be but then I found a way... and if that libpng was vulnerable, suddenly we've gained usermode execution on a Wii U. Or worse yet, similar to the Sony PSP .tiff image exploit, maybe after gaining usermode we find a kernel-mode exploit and attack that. Now, we're near the realm of game piracy and private keys.