Linux

t’s especially bad for software engineers who are developing applications that need on a non-security big fix or new feature

This is what they tell themselves. That they need that fix. So then developers get themselves unstable packages — but wait! If they update just one version further, then compatibility will with something broken, and that requires work to fix.

So what happens is they pin and/or vendor dependencies, and don't update them, even for security updates. I find this quite concerning. For example, Rustdesk, a popular rust based remote desktop software. Here's a quick audit of their libraries using cargo-audit:

[nix-shell:~/vscode/test/rustdesk]$ cargo-audit audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 742 security advisories (from /home/moonpie/.cargo/advisory-db)
    Updating crates.io index
warning: couldn't update crates.io index: registry: No such file or directory (os error 2)
    Scanning Cargo.lock for vulnerabilities (825 crate dependencies)
Crate:     idna
Version:   0.5.0
Title:     `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
Date:      2024-12-09
ID:        RUSTSEC-2024-0421
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0421

Crate:     libgit2-sys
Version:   0.14.2+1.5.1
Title:     Memory corruption, denial of service, and arbitrary code execution in libgit2
Date:      2024-02-06
ID:        RUSTSEC-2024-0013
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0013
Severity:  8.6 (high)
Solution:  Upgrade to >=0.16.2

Crate:     openssl
Version:   0.10.68
Title:     ssl::select_next_proto use after free
Date:      2025-02-02
ID:        RUSTSEC-2025-0004
URL:       https://rustsec.org/advisories/RUSTSEC-2025-0004
Solution:  Upgrade to >=0.10.70

Crate:     protobuf
Version:   3.5.0
Title:     Crash due to uncontrolled recursion in protobuf crate
Date:      2024-12-12
ID:        RUSTSEC-2024-0437
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0437
Solution:  Upgrade to >=3.7.2

Crate:     ring
Version:   0.17.8
Title:     Some AES functions may panic when overflow checking is enabled.
Date:      2025-03-06
ID:        RUSTSEC-2025-0009
URL:       https://rustsec.org/advisories/RUSTSEC-2025-0009
Solution:  Upgrade to >=0.17.12

Crate:     time
Version:   0.1.45
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Severity:  6.2 (medium)
Solution:  Upgrade to >=0.2.23

Crate:     atk
Version:   0.18.0
Warning:   unmaintained
Title:     gtk-rs GTK3 bindings - no longer maintained
Date:      2024-03-04
ID:        RUSTSEC-2024-0413
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0413


Crate:     atk-sys
Version:   0.18.0
Warning:   unmaintained
Title:     gtk-rs GTK3 bindings - no longer maintained
Date:      2024-03-04
ID:        RUSTSEC-2024-0416
URL:       https://rustsec.org/advisories/RUSTSEC-2024-0416

I also checked rustscan and found similar issues.

I've pruned the dependency tree and some other unmaintained package issues, but some of these CVE's are bad. Stuff like this is why I don't trust developers to make packages, they get lazy and sloppy at the cost of security. On the other hand, stable release distributions inflict security upgrades on everybody, which is good.

Yeah, I got to thinking about this more after I posted, and it’s a horrible idea. It’d guarantee system updates break user installs, and the only way it couldn’t were if system installs knew about user installs and also

???. This is very incorrect. I don't know where to start. If a package manager manages it's own dependencies/libraries, like nix portable installs, or is a static binary (e.g: soar), then system installs will not interfere with the "user" package manager at all. You could also use something like launchd (mac) or systemd users services (linux) to update these packages with user level privileges, in the user's home directory.

Also, I don't know where you got the idea that flatpaks manage "system level" software.

It all drives me back to the realization that the best solution is statically compiled binaries, as produced by Go, Rust, Zig, Nim, V.

I dislike these because they commonly also come with version pinning and vendoring dependencies. But you should check out Soar and it's repository. It also packages appimages, and "flatimages", which seem to be similar to flatpaks but closer to appimages in distribution.