Static linking pitfalls, harms and chalenges

Speaker: Bastien Roucariès

Track: Packaging, policy, and Debian infrastructure

Type: Academic paper

Room: Petit amphi

Time: Jul 15 (Tue): 11:30

Duration: 0:20

A static library or a statically linked library contains functions and data that can be included in a computer program at build-time such that the library does not need to be accessible in a separate file at run-time. Static linking is an old concept that, during the 2000s, was considered a legacy approach and was gradually phased out in favor of dynamic libraries.

Dynamic libraries offer significant advantages in code reusability, security, and memory efficiency. In contrast, static libraries provide potential speed optimization by reducing dead code and enabling seamless code integration without relying on API or ABI stability, including the application of custom patches to upstream code.

In the 2010s, this seamless code integration became known by various terms, such as vendoring (Go terminology), packing, bundling, browserifying (JavaScript terminology), and uber-jar (Java terminology). At its essence, it represents a form of static linking, even within interpreted languages.

The widespread use of static linking presents significant challenges for release managers and security managers. While some workarounds, such as Static-Built-Using fields, binNMU, or mass rebuilds, exist, they are often insufficient or overly cumbersome in practice.

Moreover, following a Thompson-like argument, a ‘Reflections on Static Trusting Trust’ approach should be undertaken from a security perspective to ensure the removal of insecure code. Practical assistance could be obtained from reproducible builds, though these lack theoretical guarantees.

Introducing new concepts, such as weak dynamic linking and leaf static linking, could help alleviate certain challenges and contribute to improving the current status quo.