4 ms·

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 h

by jerf 1y ago

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.

AndyMcConachie 1y ago
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 1y ago
  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 1y ago
    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.
sim7c00 1y ago
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 1y ago
  > 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 1y ago
    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".
  - sim7c00 1y ago
    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...).
  - homebrewer 1y ago
    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.
inetknght 1y ago
> 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.

by jerf 1y ago

AndyMcConachie 1y ago

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 1y ago
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 1y ago
  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.

sim7c00 1y ago

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 1y ago
> 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 1y ago
  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".
- sim7c00 1y ago
  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...).
- homebrewer 1y ago
  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.

inetknght 1y ago

> 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.