ABI stability can block security updates [LWN.net]

ABI stability can block security updates

Posted Nov 27, 2025 18:14 UTC (Thu) by DemiMarie (subscriber, #164188)
In reply to: Shared libraries by nim-nim
Parent article: APT Rust requirement raises questions

Static linking allows security updates to libraries to be applied to applications that are ready for them, even when other applications are stuck on vulnerable versions. See gRPC in Fedora.

to post comments

ABI stability can block security updates

Posted Dec 1, 2025 9:17 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

Unfortunately baddies do not care if you have double plated the main door with the latest uber-expensive alloy, if the service door right next still uses rotting medium (a very common situation in proprietary setups).

What matters for security is that *every* deployed software bit uses fully patched components, even when those components are slightly old because no security event required their update and a full OS update is expensive effort-wise.

Static linking as you wrote promotes fixing highly visible main doors while keeping service doors wide open.

ABI stability can block security updates

Posted Dec 1, 2025 10:50 UTC (Mon) by taladar (subscriber, #68407) [Link]

You are completely ignoring that dynamic linking keeps the entire distro on an old version (or rather often a new, completely untested version somehow considered stable because it is called a "backported fix") because the many less popular programs that most systems don't even install have not been updated yet.

ABI stability can block security updates

Posted Dec 1, 2025 10:59 UTC (Mon) by muase (subscriber, #178466) [Link]

But that’s not true, as different components have different attack surfaces. gRPC is a good example, because it’s a huge difference if you have a public service that works with untrusted gRPC messages from the outside, or if your coordinator just uses a fixed set of gRPC messages to distribute your physics simulation across multiple worker processes via stdin/stdout on your own desktop.

In the first case, that’s a real-world RCE, in the second case you probably cannot even exploit the bug because you can’t control the input in the first place (messages are generated by the coordinator, not you).

Different use cases have different attack scenarios and different attack surfaces. There are tons of applications where a gRPC vulnerability will be a serious incident; but there are also a lot of cases where it – realistically speaking – it’s simply not exploitable.

Ideally, you should fix all bugs asap – but given the limited resources IRL, it sometimes is simply necessary to triage. That includes that if you cannot fix all packages at once, you can at least try to fix those where the bug has the most impact; i.e. users*impact (“reduce the bleeding”). It simply does not make sense to hold a fix back for the majority of users because you’re blocked by some obscure package nobody is using, or to wait for a package where the bug has no relevant real-world impact.