I've also seen really wonderfully-written scripts that, if you read them manually, allow you to change where whatever it is is installed, what features it may have, optional integration with Python environments, or other things like that.

I at least skim all the scripts I download this way before I run them. There's just all kinds of reasons to, ranging all the way from the "is this malicious" to "does this have options they're not telling me about that I want to use".

A particular example is that I really want to know if you're setting up something that integrates with my distro's package manager or just yolo'ing it somewhere into my user's file system, and if so, where.

▲

inetknght 2 days ago | parent | next [-]

> I've also seen really wonderfully-written scripts that

I'll take a script that passes `shellcheck ./script.sh` (or, any other static analysis) first. I don't like fixing other people's bugs in their installation scripts.

After that, it's an extra cherry on top to have everything configurable. Things that aren't configurable go into a container and I can configure as needed from there.

▲

sim7c00 2 days ago | parent | prev | next [-]

right? read before u run. if you cant make sense of it all, dont run. if you can make sense of it all, you're free to refactor it to your own taste :) saves some time usually. as you say, a lot are quite nicely written

▲

groby_b 2 days ago | parent [-]

> read before u run

Lovely sentiment, not applicable when you actually work on something. You read your compiler/linker, your OS, and all libraries you use? Your windowing system? Your web browser? The myriad utilities you need to get your stuff done? And of course, you've read "Reflections on trusting trust" and disassembled the full output of whatever you compile?

The answer is "you haven't", because most of those are too complex for a single person to actually read and fully comprehend.

So the question becomes, how do you extend trust. What makes a shell script untrustworthy, but the executable you or the script install trustworthy?

	▲	spookie 2 days ago \| parent \| next [-]
		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".
	▲	homebrewer a day ago \| parent \| prev \| next [-]
		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.
	▲	jerf a day ago \| parent \| prev \| next [-]
		"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.
	▲	sim7c00 a day ago \| parent \| prev [-]
		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...).

▲

AndyMcConachie 2 days ago | parent | prev [-]

100% agree. The question of whether I should install lib-X for language-Y using Y's package management system or the distribution's package management system is unresolved.

▲

Diti 2 days ago | parent [-]

It’s solved by Nix. Whichever package management you choose (nixpkgs or pip or whatever), the derivation should have the same hash in the Nix store.

(Nix isn’t the solution for OP’s problems though – Nix packages are unsigned, so it’s it’s basically backdoor-as-a-service.)

	▲	ants_everywhere a day ago \| parent [-]
		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.