This looks great and all, but trying to read and digest a multi hundred line bash script seems unrealistic. Full send pipe into bash.
replies(1):
Most installers are doing the same basic patterns: checking for dependencies, checking the distro, etc. It’s not hard to figure these out and spot them in different scripts.
For me personally, I try to use a distro/platform specific package if it exists, since hopefully that means at least one human has read through some of the code, and probably installed it. If that’s not available, I do download the script to review before executing it (and not re-downloading it to pipe to a shell). I’m sure I wouldn’t catch everything, but I would probably catch odd embedded curl calls and the like.
As I already said years ago[1], if you want to hide some nefarious stuff then you'd do it in something like autoconf soup, or something like that. The install.sh is just too obvious of a place. And this is exactly what happened in the real-world xz attack. I can guarantee you very few, if any, packagers are auditing all of that. And even if they did: it's just so easy to miss.
Tons of devs download thousands of NPM packages as well, and each can execute code upon install, so a single curl-to-shell pipe from a HTTPS endpoint from a domain you checked always felt way safer than any `npm install`, and so a pretty minor in comparison and yet it gets a lot more attention than package manager, which _feels_ like security cargo culting. Plenty of supply chain attacks in package managers of course. But yeah, would like to be corrected if that intuition is wrong.