build scripts for static binaries
- C 85.6%
- Roff 12.8%
- Makefile 1.6%
|
David Goerger
ab6c3146b7
update to mail/mutt 2.4.1
Change-Id: Ia026968ace5bc26cd5f483b60348d64528bd6bcc Reviewed-on: https://review.daemonica.net/c/dgoerger/static-bins/+/1766 Reviewed-by: David Goerger <dgoerger@daemonica.net> |
||
|---|---|---|
| linux | update to textproc/less 704 | |
| netbsd | update to mail/mutt 2.4.1 | |
| README | fix previous | |
static-bins =========== This repo provides build scripts for statically-linked binaries, currently targeting limited use cases on Linux and NetBSD. Why static? ----------- Generally-speaking, statically-linked binaries are a poor choice for the average person due to vendoring of external libraries, which then are never upgraded against security vulnerabilities until the next time the binary is recompiled. Dynamic-linking solves that problem, and for general purpose computing is usually what you want. Statically-linked binaries are nevertheless useful in a few limited circumstances: 1. Limited security exposure. For example, the `mutt` build omits support for TLS (reducing exposure to OpenSSL vulnerabilities), and mitigates this by also omitting support for network-based protocols like IMAP4 and POP3. The resulting binary is thus only useful for reading and replying to `/var/mail` on localhost. 2. The binary needs to run on multiple versions of an OS, and you don't have access to install or rebuild proper, distro-native packages. Vendoring dependencies means we don't have to worry about soname version changes across operating system versions. 3. Some users want to opt into newer software ahead of the curve. If a user can simply plop the updated binary into `$HOME/bin` and relaunch the app to test updates, that's easier than coordinating limited-release operating system package updates. 4. The operating system provides an inferior implementation of the application, and users want a better one. For example, the NetBSD implementation of `sort(1)` doesn't support the `-h` flag, which is extremely useful. Compiling and providing the OpenBSD version of that program, asynchronously of NetBSD system library changes through the power of static linking, solves this problem. 5. Unreliable updates on shared systems. I occasionally run into an issue where the system administrator of a shared system will, for example, upgrade OpenSSL, changing the soname of the dynamic libraries, and then not remember to rebuild world to fix dependent programs. This is generally a solved problem, and it's always surprising to me when this happens; nevertheless it does, albeit with decreasing frequency as fewer admins perform yolo package upgrades without the help of a package manager. Linking statically avoids any such nonsense caused by this sort of administrative oversight. 6. Rescue binaries. If an, uh, enterprising administrator has attempted an ill-advised in-place upgrade of system libraries without the assistance of a package manager, a statically-linked visual editor like `nano` will be a welcome reprieve from the standard rescue line editor, `ed(1)`. Isn't this problem better solved by package managers? ----------------------------------------------------- At a technical level, yes, but sometimes static linking is simply more expedient.