1·
20 hours agoOpenstack cluster!
- 0 Posts
- 11 Comments
Joined 2 years ago
Cake day: August 10th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
11·22 hours agocurl -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-0416I 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?
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.
It’s not just protection against security, but also human error.
https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123
https://hackaday.com/2024/01/20/how-a-steam-bug-once-deleted-all-of-someones-user-data/
Just because I trust someone to write a program in a modern language they are familier in, doesn’t mean I trust them to write an install script in bash, especially given how many footguns bash has.
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.”.