Flatpaks won't be automatically recompiled though. It might take years before they bump whatever vulnerable thing they are using.

> What’s to guarantee applications haven’t statically linked a library (in whatever version) rather than linked a “system” version of a library?

It's easy to see which commands are given to the compiler and if there is a copied library if you have sources.

> Flatpaks won't be automatically recompiled though. It might take years before they bump whatever vulnerable thing they are using.

If we made all builds reproducible (like oasis) we could setup an automated trusted system that does builds verifiably automatically (like what Nix has).

There are already trusted sources of software packages that provide security updates: traditional Linux distributions.

Doing automated, local patching and rebuilding is far from enough. You need experts to correctly backport patches and test them thoroughly.

No, no… We need to move very fast, and break all the things. Tradition and conservatism is not the way. We need to compile everything and anything. Change the paradigm, break the status quo!

Oh, just like Gentoo, Slackware and LFS. ;)

Seriously, maybe we shouldn’t ignore history and learn why things are like this today.

People bashing distributions seem to ignore that the alternative is the google play store.

Which reproducible builds project is striving to do for quite some time.

It’s not just a simple switch you flick and recompile.

Yes but in general a system can safely be assumed to contain At least some software which was built elsewhere. Especially in more proprietary worlds like on Windows and MacOS.

> And for almost all systems I’d say “yes, absolutely”.

Do you even understand that you are advocating in favour of perpetually vulnerable systems?

Let's not touch the fact that there are vague and fantastic claims about shared libraries being this never ending sources of problems (which no one actually experiences) that when asked to elaborate the best answer is wand waving and hypotheticals and non-sequiturs.

With this fact out if the way, what is your plan to update all downstream dependencies when a vulnerability is identified?

Before you decry statically linked systems as "perpetually vulnerable", I'd advise you take a look at the number of privilege escalation vulnerabilities caused by LD_PRELOAD alone.

> Before you decry statically linked systems as "perpetually vulnerable"

But statically linked systems are perpetually vulnerable by design, aren't they?

I mean, what's your plan to fix a vulnerable dependency once a patch is available?

Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications?

Because with shared libraries, all it takes to patch a vulnerable library is to update just the one lib, and all downstream consumers are safe.

What's your solution for this problem? Do you have any at all?

What's your plan if fixing a vulnerability requires changing the size of a struct?

> What's your plan if fixing a vulnerability requires changing the size of a struct?

Do you actually have an answer any of the points I presented you, or are you going to continue desperately trying to put up strawmen?

If any of your magical static lib promises had at bearing in the real world, you wouldn't have such a hard time trying to come up with any technical justification for them.

The argument that you seem to be making is that under dynamic linking, there is never any reason to need to recompile an application, and thus the fact that static linking forces you to recompile applications makes it non-viable from a security perspective.

Unfortunately, this is very far from being true in the real world.

And even if all libraries did maintain 100% ABI compatibility forever, and even if there were never any compiler or processor bugs that needed to be mitigated by recompiling applications, dynamic linking would still add runtime complexity and thus surface area for security vulnerabilities.

> Are you tracking each and every dependency that directly or indirectly consumes the vulnerable library? Are you hoping to have access to their source code, regardless of where they came from, and rebuild all libraries and applications?

Yes? I mean, are you just throwing random untrusted binaries onto your servers, not keeping track of what their dependencies are, and hoping to God that you will never ever need to recompile them? (And if your explanation for that is "I use proprietary software from vendors who refuse to share source code", have you chosen incompetent vendors who cannot respond to security vulnerabilities in a timely fashion?)

What is your plan?

Four-part plan is this:

1. For each application and library in the system, maintain a copy of the source code and the scripts necessary to rebuild it.

2. Keep track of the dependency tree of each application and library in the system.

3. If there's a problem with a dependency, update it and rebuild all dependent applications.

4. If I'm using binaries from a vendor (whether that's a Linux distribution or a proprietary software company), the vendor needs to be responsible for (1) to (3).

In practice, your package manager will generally implement almost all of (1) to (3) for you. (Newfangled systems like NPM or Cargo usually do it using lockfiles and automated tools like Dependabot.)

If you're using dynamic linking, guess what? You still have to do these four things, because even with dynamic linking, there are still problems that can only be solved by recompiling your software. Even if you think reasons like ABI incompatibility or processor bugs aren't compelling, there might be, y'know, bugs in the applications themselves that you've gotta patch.

> If I'm using binaries from a vendor (whether that's a Linux distribution or a proprietary software company), the vendor needs to be responsible for (..)

I'm not even going to bother pointing how unfeasible all your other points are. I'm just going to point this Fack: you do understand this does not work and never worked at any point in time, don't you?

Do you understand the explicit reference to perpetually vulnerable systems? Do you realize where it cames from?

You only have the power to rebuild the packages you own personally, and even so static libs offer zero ways to keep track of which version went into which build.

Once your fantastic panacea starts to rely on your idea to force third parties to follow your personal orders to make new releases under your own personal terms, you should be very aware that you will not get your wish. You'll instead just keep on using the same vulnerability-riddled release.

Do you understand the importance and value of static libs? You do not need four-point authoritarian and deeply impractical and unfeasible plans to keep your system safe. With shared libraries you just patch the one lib, and all your system is safe.

And again what tradeoff do you want to achieve for this? Nothing?

That's like claiming that a leaky sump pump sank the titanic.

Linux has never been anywhere close to resistant to privilege escalation bugs.