I think Homebrew still makes a mess with permissions on multiuser systems (at least on macOS), so it's probably not a good example of best practices.

While true, then I'd just skip installing these products and find another way. And if this is the only way and the product is important (say, brew), make an exception.

Is there really a supply chain vulnerability of you inspect the app and never update it?

This is, for me, a "set and forget" kind of tool -- why would i need to update a script?

No, not really. This reads like ornate hand waving to distract from different threat models and situations.

A lot of safety is down to accountability. A distribution through an attributable marketplace or being verifiably signed.

Safety isn't a performative action, so reading a script may still confuse you or you may miss subtleties. But opting for a safer install mechanism makes a huge difference, which is we always ought to prefer apt, dnf, over the likes of curlbash, brew, npm.

> If you read the script before you pipe it into your shell, it's safe.

This isn't strictly true. It's possible to detect on the server side if curl is being piped and deliver different content: https://web.archive.org/web/20241224173203/https://www.idont...

> If you read the script before you pipe it into your shell, it's safe.

If you download it first before executing it (instead of downloading it a second time when executing it), then that mitigates one problem, but still not all of them (like you mention). Other mitigations are also possible, such as hashing, certificate pinning, sandboxing, etc.

If you read the script before piping it into your shell, you're doing better than (I'm guessing) 90% of people, but it's still possible that the attacker who got you to copy https://xn--nstall-ovf.xn--example-cl-62i.dev into your terminal has also made similarly-hard-to-spot changes to the install script. E.g. if it downloads a .deb package from https://xn--nstall-ovf.xn--example-cl-62i.dev (same Cyrillic і character in there that looks like a Latin i but isn't), you might not spot that by reading the script.

But IMHO, your "unopened bottle of ketchup" analogy doesn't work. These days, the likelihood of someone trying to trick you into running arbitrary code disguised as an install script is so much higher than the chance that someone working at the ketchup bottling plant is deliberately contaminating bottles before they go out.

> It's about as safe as trusting all the add-ons in your IDE, and all the packages your node app pulls from random package repos.

Absolutely incorrect. You can do far easier due dilligence for IDE plugins

This is why we have linux distributions with maintainers who can take at least a basic look at the software, vet dependencies and run it through a test suite. And they only have to do that once for each new version and not again and again for each download.

Linux distributions contain a curated set of packages. And, if any, distros like Guix can import NPM crap and at least place it under an isolated container for work so the rest it's unharmed.