I asked Ariadne Conill from the Alpine project about this. She says they don't static link.

Here's a copy/paste of her response from LinkedIn (https://www.linkedin.com/feed/update/urn:li:activity:7180667...)

> Alpine is dynamically linked, we just do not link SSH against libsystemd. In general, I think systemd needs to split up the various components in libsystemd into separate libraries, as there is no reason sd_notify() would ever require liblzma.

> Anyone who is claiming that Alpine is secure because it's staticly linked have clearly never actually looked at a running Alpine system. I blame the initial Rust PR for musl support for starting this whole "musl = static linking" meme.

> [Alpine] just do not link SSH against libsystemd

Arch doesn't either.

In fact, official releases of openssh-portable don't. One has to patch it for that. Debian and Fedora (as well as their downstreams) do apply such a patch [1]. Most other distros don't.

[1] https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...

> Alpine is dynamically linked, we just do not link SSH against libsystemd. In general, I think systemd needs to split up the various components in libsystemd into separate libraries, as there is no reason sd_notify() would ever require liblzma.

Funny, I was thinking about this just now. I get that the average library size on npm and such is on the wrong end of the spectrum, but libsystemd seems to swing far into the other end of the spectrum. Functions ranging from pretty much C-Code based on the stdlib with a few handlers, like sd_notify, hardware state detection and handling to systemd-journald file vacuuming all in that one library? Phew.

(And no, this is no discussion about systemd, that's just a thought about library design)

Ah hah! Indeed I’m most familiar with musl in a static linking context.

Thanks for the clarification