Binaries in the Linux world are usually retrieved the "Official Way". You use a distro. Therefore you trust "them" and how they operate their package manager.

This is the "Unofficial Way".

Non-system software, which is what often gets installed with this method, typically does not get root privileges on my systems, or at least is not expected to write anything into directories like /usr.

These scripts are often written by people who only know one OS well (if any), and if that OS is macOS, and you're on Linux (or FreeBSD, or whatever), you can expect them to do weird shit like sticking binaries into /usr/bin in circumvention of the package manager, or adding their own package repositories without asking you (and often not whitelisting just their packages, which allows them to e.g. replace glibc on your system without you noticing), etc.

It's not comparable to simply using the already installed software.

"What makes a shell script untrustworthy, but the executable you or the script install trustworthy?"

Supply-chain attacks. Linux distros have a long history of being more hardened targets than "a static file on some much, much, much smaller project's random server".

Also things like linux packages or snaps or flatpaks are generally somewhat ringfenced by their nature. Here I don't mean for security reasons per se, but just by their nature, I have confidence a flatpak isn't going to start scribbling all over my user directory. A script may make any number of assumptions about what it is OK to do, where things can go, where to put them, what it can install, etc.

"Trust" isn't just about whether something is going to steal my cryptowallet or install a keylogger. It's about whether it breaks my reproducible ops setup, or will stick configuration in the seventeenth place in my system, or assumes other false things about how I want it set up that may cause other problems.

well read before u run was obviously for the shell script not gcc sources :'l. i dont think thats a fair comparisson. but you do make a good point. its why i write my own OS :D and yes, once that is up own toolchain would be next, as an experiment to see what'd be needed to be secure ,even forgetting ofc the hw we run on. wasnt planning to play with horrible acids to see what is in there, tho its possible.. :D. (it will never be finish in my life haha, i know...).

The Nix installer is one of the more shocking curl | bash experiences I've had.

It created users and groups on my system! And the uninstall script didn't clean it up.

> You are essentially asking what is safer than running arbitrary code from the internet

No, I'm asking what is a safer method when I want to install some code from the internet.

> The OS usually has guardrails and logging and audits for what is installed but this bypasses it all.

Not everything is packaged or up-to-date in the OS

> My mom recently got fooled by a scammer that convinced her to install remote access software.

Remote access software are packaged in distros too.

> My mom recently got fooled by a scammer that convinced her to install remote access software.

But I bet she didn't install it with curl piped to bash. The point isn't that curl|bash is safe, but that it isn't inherently more dangerous than downloading and running a program.

I've installed untold thousands of .deb packages in my lifetime - often "officially" packaged by Debian or Ubuntu, but in many cases also from a software vendor's own apt repository.

Almost every one contains preinst or postinst scripts that are run as root, and yet I can count on zero hands the number of times I've opened one up first to see what it was actually doing.

At least a curlbash that doesn't prompt me for my password is running as an unprivileged user! /shrug

a lot of useful packages are not in package managers, or are in old versions that lack features u need. so its quite common to need to get around that...

Getting every software into every distro is not feasible, it's a NxM problem. Sometimes this encourages the use of third-party repositories, which I would argue is even unsafer because it requires root access.

Flatpak is a nice suggestion but unfortunately it doesn't seem to work nicely for CLIs.

> "Back in the day" we cloned the source code and compiled ourself instead of distributing binaries & install scripts.

Isn't that the same thing with the extra step of downloading a git repo?

Funny enough clone and compile is easier now than ever before. You can ask a llm to create a docker to compile any random program and most of the time will be okay.

R/O root means a a binary will fail to install, but won’t stop my homedir being backdoored in a DD Orion to the huge waste of time that attempting an RO root would be.

curl | tee foo.sh

and then inspect foo.sh and then (maybe) cat foo.sh | bash

Does that avoid the issue?

Flatpak and AppImage.

Or download & compile & install to a PREFIX (e.g. ~/.local/pkg/), and use a symlink-manager to install to e.g. ~/local (and set MANPATH accordingly, too). Make sure PATH contains ~/.local/bin, etc. It does not work with Electron apps though. I do "alias foo="cd ... && ./foo".

> Because you're making system-wide changes which affect more than just your user?

Am I? How am I affecting other users by installing something for myself?

Even Windows has had "Install just for this user or all users?" for decades

Repos and maintainers etc. are just a long unauditable supply chain [1]. And everyone is encouraged to blindly trust this chain with sudo access.

It's worse than that. If your distro doesn't have some package, you're encouraged to just add PPA repos and blindly trust those.

Quite a few companies run their own repos as well, and adding their packages is again `sudo add repo; sudo install`

Yes, it's not as egregious as just `curl | bash`, but it's not as far removed from it as you think.

[1] E.g. https://en.wikipedia.org/wiki/XZ_Utils_backdoor

The Applications folder system does work really well for GUI apps! It's not really made for command line apps.

For command line apps, the equivalent would probably be statically-compiled binaries you can just drop somewhere in your PATH, e.g. /usr/local/bin/. For programs that are actually built this way (which I would personally call "the correct way") this works great!

> Not all 3rd party developers seem to have gotten that memo

This frustrates me to no end on macOS. Not only do you see crappy installers like you said, but a ton of applications now aren't even self contained in ~/Applications like they should be.

Apps routinely shit all over ~/Library when they don't need to, and don't clean up after themselves so just deleting the bundle, while technically 'uninstalls' it, you still have stuff left over, and it can eat up disk space fast. Same crap that Windows installers do, where they'll gladly spread the app all over your file system and registry but the uninstaller doesn't actually keep track of what went where so it'll routinely miss stuff. At least Windows as a built-in disk clean up tool that can recognize some of this for you, macOS will just happily let apps abuse your file system until you have to go digging.

Package managers on Linux solved this problem many, many years ago and yet we've all collectively decided to just jump on the curl | bash train and toss the solution to the curb because...reasons?

> …did they have to go with "curl | bash"?

That's one of many options, documented at the first text link of the home page. https://docs.brew.sh/Installation

I've been using MacPorts since before homebrew existed and never switched away.

Lately I've been using devbox (nix wrapper) for my homebrew-like needs via "devbox global add <whatever>", for project specific setup I stick with mise (asdf-compatible)."

I don't like homebrew because I've been burnt multiple times because it often auto-updates when you least want it to and breaks project dependencies.

And there's no way to downgrade to a specific version. Real package managers typically support versioning.

MacPorts is a good alternative, but you'll find that Homebrew is absolutely not the worst. Personally, I find brew fast and reliable. Look at mise (`brew install mise`) for managing any developer dependencies. https://mise.jdx.dev/

I am a fan of Gentoo Prefix. Others like pkgsrc.

nix possible with lix, if you can stomach nix syntax.

apt and yum/dnf are pretty great