Until there's a vulnerability in one of the dependencies and now you have to rebuild all of the packages which use it. Specifically for Rust, there's also the fact that most projects use a lock file and if your build process respects it, you now have to wait for the upstream to update it and release a new version (or update it yourself). And if your build process doesn't respect the lock file (or the project doesn't use it) and you just fetch the latest compatible dependencies at the time of build, you now have no idea if you're affected or not by the vulnerability because you don't have the exact resolved versions stored anywhere (https://github.com/rust-lang/rfcs/pull/2801).

Packages get rebuilt all the time. This is fine.

As for the rest, it would be cool if binaries shipped with a manifest of some sort naming all the versions of their statically included dependencies. A SBoM of sorts. It would make this sort of vulnerability scanning much easier to do.

Go binaries have that. You can apply "go version -m" to any recent Go binary.

Also "govulncheck".

Examples:

    go version -m $(which go)
    go install golang.org/x/vuln/cmd/govulncheck@latest
    go version -m $(which govulncheck)
    govulncheck -mode=binary $(which govulncheck)
    for b in $(go env GOPATH)/bin/*; do govulncheck -mode=binary "$b"; done

Scanning, sure. Fixing... surely much harder than with shared libraries.

It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.

You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.

You also now get a huge set of users who will now download these 1k of updated packages. Not to mention the utter fun of trying to understand why your system just requires maybe 100 packages to be updated…

Compare to upgrading a single shared library.

At large timescales, yes. But not at timescales relevant for rapid security updates.

They get rebuilt when a change in the package is made, not when a change in a dependency is made — which is a huge difference.

There are plenty of packages that might not get an update for a long time (month, half year, … whatever their release cadence might be).

Dynamic linking makes it _easier_ to handle security, including checking if your program is linking to a broken library — static linking does not have the same means.

Statically linked programs don’t mean you know what is being run either, you can always dlopen() and all kind of shenanigans like Go and Rust do.

What is a security nightmare is statically linked binaries, you have no clue what they are linked against.

Debian did the strongest push for reproducible builds, and is 100% source available.

Enclaves like Go, Rust, Swift (things that insist on using direct sys calls, and eschewing system libraries) would need to implement their own versions, or use FFI, and then you're SOL anyway if you really insist to use static linking... And who knows what kind of bugs might crop up there that don't match whatever anything anyone else uses.

Shrug :-)

AFAIK, the reason most Linux distributions have an allergic reaction to static linking is because of zlib. There was a vulnerability in zlib some time ago, and it required the distributions to find every single program which had its own copy of zlib (vendoring zlib used to be common back then), update these copies with the security fix (not necessarily trivial, since the vendored copy might be a customized variant of an older zlib release), and rebuild all these packages (which is a lot of "fun" when some of the packages are in a "failed to build from source" aka FTBFS state). The distributions learned their lesson back then.

On the other side, there are quite a few self-updating applications out there (browsers), and source control systems like Github will push notifications, and even pull requests for out of date dependencies. So pushing out a new version of a given application is pretty easy. If the application comes through Flathub or self-updates then it doesn't have to wait for the distro maintainers to get the update out.

The amount of work spent finding usages of static linkage, and figuring out which version of libxz (or whatever it was called) just to be very sure that one wasn't using the compromised version was atrocious, no thanks.

No, but it has to wait for each developer of each binary individually. Instead of relying on a team of maintainer, you now rely on all the developers.

"Self-update" isn't something magical: someone has to do build the new version and ship it. With static linking you still have to build and ship for every. single. binary. With dynamic linking you just build and ship the one library that everybody depends on.

I tend to keep my host OS pretty bare, and most of my runtime apps in Flatpak and the stuff I'm working on in Docker.

Do you have experience with that, or do you say it because you believe it's possible? Genuinely interested, because I have been looking into it and my conclusion was that it does not really do what I expect from "dynamic linking".

See e.g. https://news.ycombinator.com/item?id=40665343 and https://news.ycombinator.com/item?id=40661874

For randomly downloaded binaries from the internet it means you will most likely keep using it with the vulnerabilities for years to come.

Yes, for you as a user it's simpler to link statically and not learn about anything else. But distros are a bit more elaborate than that.

I’m happy for someone to update the version of my dependency if it has security patches. But the rest? A total nightmare. I’ll take cargo / npm / swift / etc style versioning every day.

If you make open source software, the solution is simply that you should not distribute your software [1]. Let distro maintainers do it, and suddenly it's a lot easier for you.

If you make proprietary software, then it's not exactly the problem of the Linux distros anymore so sure, feel free to link statically. I personally think you should do a mix of both: libraries like openssl you want to link dynamically from the system. Now some obscure dependency you may have that breaks compatibility randomly and is generally not distributed by major distros, probably you want to link them statically. But you should know that you are then responsible for them and the security issues they may bring (i.e. you should monitor them and update them regularly).

[1]: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...

You forgot to link the image with the dog sitting in the fire.

Static linking comes with a lot of issues, just like dynamic linking is not perfect. I really think it depends on the use-case, and that's why I want to have the choice.

IIRC Arch does as well (or at least tries to).

The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust.

What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.

Everything about the shared lib model is stupid, and has contributed to poor Linux market share to date.

> Everything about the shared lib model is stupid

I don't think we can discuss if that's you're stance. But also I don't think you understand the shared lib model if you think like that.

Rust supports dynamic linking, and has since well before 1.0.

> Yes, it's more painful for end users than just typing `cargo build`

Cargo is fine, I don't mind installing cargo. I just don't want my packages to be handled by my package manager. I don't want every project to ship their own custom package manager like rustup.

I don't understand why one would think this. You make it sound as though Rust only supports dynamic linking for glibc, but that's certainly not true.

I've seen plenty of bad go libraries. For example their authors will be unaware of isatty() so they will output control codes when piped.

If you factor in the time to find a competently written library (and quite possibly write one yourself) it starts to be less convenient.

What does that mean?

The one where the only sane option is using distribution packages or conda and ignoring anything that the python community comes up with?

Ok installed Meson also from my distro packages! But no, the project required a newer Meson version.

Ok let's install Meson with pip! But no, it turns out pip packages themselves can require a minimum pip version!! Go figure.

So I couldn't build that program without first pip-installing Meson, and I couldn't pip-install Meson without first pip-installing a more modern version of pip itself.

Guess how well it worked when I upgraded pip. Spoiler: not a smooth way to discover that Python packaging is a joke.

This is exactly what Node/NPM does: "npm instal" creates a new dir, "./node_modules" and installs stuff there, and next "npm" commands will transparently refer to that subdir. This is, in effect, the same thing as a Python's venv! to the point that in my scripts I always name them "python_modules", to give other unfamiliar devs a clue of what it is.

If "pip install" just did this transparently, without introducing the whole concept of venvs to the user, it would be a huge step forward. I cannot imagine how it would suck if NPM didn't make its node_module dir, and instead it forced you to first learn all the idiosyncrasies of module isolation.

I think there's a bit of a misconception here.

Ardour is written in C++ and depends on 80+ other libraries.

The dependency situation may be exacerbated by packaging culture that encourages the use of lots of relatively small dependencies, but it is by no means determined by language or even context.

When in C++ I had 2 direct dependencies it resulted in 6 total dependencies (direct + transitive).

In Rust I had 5 direct dependencies (because some standard stuff is not in the standard lib) and it resulted in... 300 total dependencies.

> but it is by no means determined by language or even context.

Not sure what you mean there. My feeling is that making it super easy to pull 50 transitive dependencies without realizing it does not help. If you have to manually handle every single dependency, first it forces you to look at them (that's a good thing), and second it encourages you to minimize them.

What is it that makes you think that C/C++ does not do this also?

[ EDIT: this also has something to do with the typical size and scope of C/C++ libraries ]

My experience. I haven't worked in a single C++ project that had hundreds of dependencies, but I encounter those regularly in Rust/npm.