moonpiedumplings

Kasmvnc?

if one needs to run a containerised service

Can you elaborate what you mean by this? Because if a service is not packaged in Nixos, you won't be able to run it in a Nixos container either. Well, you can, but you would have to package/setup it yourself.

It actually is a language issue.

Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.

But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you're program doesn't have to be GPL. It's partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn't be able to extend proprietary code off of it — not that I care about that, but the library makers often do.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it's complicated.

EDIT: Nvm I'm wrong. Rust does allow dynamic linking

Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.

EDIT2: Upon further research it seems that Rust's dynamic linking implementation lacks a "stable ABI" as compared to other languages such as Swift or C. So I guess we are back to "it is a language issue". Well thankfully this seems easier to fix than "Yeah Rust doesn't support dynamic linking at all."

Edit3: Nvm, I'm very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It's the LGPL that doesn't.

Openstack cluster!

curl -fsSL https://soar.qaidvoid.dev/install.sh | sh

I hate this, but I've mentioned before in the other threads related to this that I make an exception for package managers due to their ability to install packages themselves.

Am I just supposed to not distribute my software? And don’t say “distros will do it” because that’s clearly a shit non-solution. No distro has made a package for any of the software I’ve written.

Systems that protect people mean bureaucracy. And bureaucracy means slowness. It means many niche libraries or programs won't get packaged. It means that it won't get updated to the latest version immediately either, even if they receive security updates.

But as a consequence of these systems, Debian 12 remained entirely untouched by the XZ backdoor, when almost every other distribution was hit. That's a pretty big deal.

As a consequence of a lack of these systems, many Windows programs are still floating around with vulnerable versions of curl, having included the software into their "package" but never bothering to update it.

I care more about the security of the users than the feelings of the developers. It's that simple. Developers are a tiny fraction of total computer users. The needs of the many outweigh the wants of the few.

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.

A viable way to install something that works on all Linux distros (and Mac!), and doesn’t require root.

Nix portable installations, Soar.

The reason people use curl | bash is precisely so they don’t have to faff around making a gazillion packages.

Developers shouldn't be making packages. They do things like vendor and pin dependencies, which lead to security and stability issues later down the line. See my other comment where I do a quick look at some of these issues.

Hilarious, but not a security issue. Just shitty Bash coding.

It absolutely is a security issue. I had a little brain fart, but what I meant to say was "Security isn't just protection from malice, but also protection from mistakes".

Let's put it differently:

Hilarious, but not a security issue. Just shitty C coding.

This is a common sentiment people say about C, and I have a the same opinion about it. I would rather we use systems in place that don't give people the opportunity to make mistakes.

I wish we had a viable alternative. Maybe the Linux community could work on that instead of moaning about it.

Viable alternative for what? Packaging.

I personally quite like the systems we have. The "install anything from the internet" is exactly how Windows ends up with so much malware. The best way to package software for users is via a package manager, that not only puts more eyes on the software, but many package managers also have built in functionality that makes the process more reliable and secure. For example signatures create a chain of trust. I really like Nix as a distro-agnostic package manager, because due to the unique way they do things, it's impossible for one package's build process to interfere with another.

If you want to do "install anything from the internet" it's best to do it with containers and sandboxing. Docker/podman for services, and Flatpak for desktop apps, where it's pretty easy to publish to flathub. Both also seem to be pretty easy, and pretty popular — I commonly find niche things I look at ship a docker image.

The non-rolling distros can take a year to update a package, even if they decide to include it.

There is a reason why they do this. For stable release distros, particularly Debian, they refuse to update packages beyond fixing vulnerabilities as part of a way to ensure that the system changes minimally. This means that for example, if a software depends on a library, it will stay working for the lifecycle of a stable release. Sometimes latest isn't the greatest.

Distributions aren’t going to standardize on Arch’s APKBUILD, or Alpine’s almost identical but just slightly different enough to not be compatible PKGBUILD

You swapped PKBUILD and APKBUILD 🙃

I’m starting to think something like a yay that installs into $HOME.

Homebrew, in theory, could do this. But they insist on creating a separate user and installing to that user's home directory

What's stopping the downloaded script from wiping my home directory?

Lol. Lmao

Docker doesn't do this anymore. Their install script got moved to "only do this for testing".

Use a convenience script. Only recommended for testing and development environments.

Now, their install page recommends packages/repos first, and then a manual install of the binaries second.

If steam accidentally deleted someone's home directory in a bash script via a single error, I doubt I would catch that one myself.