ABI stability can block security updates [LWN.net]

ABI stability can block security updates

Posted Dec 1, 2025 9:17 UTC (Mon) by nim-nim (subscriber, #34454)
In reply to: ABI stability can block security updates by DemiMarie
Parent article: APT Rust requirement raises questions

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