5 ms·

My problem with curl|bash is not that the script might be malicious - the software I'm installing could equally be malicious. It's that it may be written incomp

My problem with curl|bash is not that the script might be malicious - the software I'm installing could equally be malicious. It's that it may be written incompetently, or just not with users like me in mind, and so the installation gets done in some broken, brittle, or non-standard way on my system. I'd much rather download a single binary and install it myself in the location I know it belongs in.

stouset 1y ago
Yes! What I really want from something like this is sandboxing the install process to give me a guaranteed uninstall process.
- hsbauauvhabzb 1y ago
  Why would you possibly want to remove my software?
  - ChocolateGod 1y ago
    This reminded me how if you wanted to remove something like cPanel back in the day your really only option was to just reinstall the whole OS.
- mjmas 1y ago
  tinycorelinux reinstalls its extensions into a tmpfs every boot which works nicely. (and you can have different lists of extensions that get loaded)
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?
shadowgovt 1y ago
Much of the reason `curl | bash` grew up in the Linux ecosystem is that "single binary that just runs" approach isn't really feasible (1) because the various distros themselves don't adhere to enough of a standard to support it. Windows and MacOS, being mono-vendor, have a sufficiently standardized configuration that install tooling that just layers a new application into your existing ecosystem is relatively straightforward: they're not worrying about what audio subsystem you installed, or what side of the systemd turf war your distro landed on, or which of three (four? five?) popular desktop environments you installed, or whether your `/dev` directory is fully-populated. There's one answer for the equivalent of all those questions on Mac and Win so shoving some random binary in there Just Works. Given the jungle that is the Linux ecosystem, that bash script is doing an awful lot of compatibility verification and alternatives selection to stand up the tool on your machine. And if what you mean is "I'd rather they hand me the binary blob and I just hook it up based on a manifest they also provided..." Most people do not want to do that level of configuration, not when there are two OS ecosystems out there that Just Work. They understandably want their Linux distro to Just Work too. (1) feasible traditionally. Projects like snap and flatpak take a page from the success Docker has had and bundle the executable with its dependencies so it no longer has to worry about what special snowflake your "home" distro is, it's carrying all the audio / system / whatever dependencies it relies upon with it. Mostly. And at the cost of having all these redundant tech stacks resident on disk and in memory and only consolidateable if two packages are children of the same parent image.
- fouc 1y ago
  I first encountered `curl | bash` in the macOS world, most specifically with installing the worst package manager ever, homebrew, which first came out in 2009. Since then it's spread. I call it the worst because it doesn't support installing specific versions of libraries, doesn't support downgrading, etc. It's basically hostile and forces you to constantly upgrade everything, which invariably leads to breaking a dependency and wasting time fixing that. These days I mostly use devbox / nix at the global level and mise (asdf compatible) at the project level.
  - tghccxs 1y ago
mingus88 1y ago
My problem with it is that it encourages unsafe behavior. How many times will a novice user follow that pattern until some jerk on discord drops a curl|bash and gets hits IRC used to be a battlefield for these kinds of tricks and we have legit projects like homebrew training users it’s normal to raw dog arbitrary code direcly into your environment
- SkiFire13 1y ago
  What would you consider a safer behaviour for downloading programs from the internet?
  - thewebguyd 1y ago
    Use your distro's package manager and repos first and foremost. Flatpak is also a viable alternative to distribution, and if enabled, comes along with some level of sandboxing at least. "Back in the day" we cloned the source code and compiled ourself instead of distributing binaries & install scripts. But yeah, the problem around curl | bash isn't the delivery method itself, it's the unsafe user behavior that generally comes along with it. It's the *nix equivalent of downloading an untrusted .exe from the net and running it, and there's no technical solution for educating users to be safe. Safer behavior IMO would be to continue to encourage the use of immutable distros (Fedora silverbue and others). RO /, user apps (mostly) sandboxed, and if you do need to run anything untrusted, it happens inside a distrobox container.
    - sim7c00 1y ago
      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...
    - hsbauauvhabzb 1y ago
      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.
    - 1y ago
nikisweeting 1y ago
This is always the beef that I've had with it. Particularly the lack of automatic updates and enforced immutable monotonic public version history. It leads to each program implementing its own non-standard self-updating logic instead of just relying on the system package managers. https://docs.sweeting.me/s/against-curl-sh https://docs.sweeting.me/s/against-curl-sh
IgorPartola 1y ago
This exactly. You never know what it will do. Will it simply check that you have Python and virtualenv and install everything into a single directory? Or will it hijack your system by adding trusted remote software repositories? Will it create new users? Open network ports? Install an old version of Java it needs? Replace system binaries for “better” ones? Install Docker? Operating systems already have standard ways of distributing software to end users. Use it! Sure maybe it takes you a little extra time to do a one off task of adding the ability to build Debian packages, RPM, etc. but at least your software will coexist nicely with everything else. Or if your software is such a prima-donna that it needs its own OS image, package it in a Docker container. But really, just stop trying to reinvent the wheel (literally).
1vuio0pswjnm7 1y ago
Many times a day both in scripts and interactively I use a small program I refer to as "yy030" that filters URLs from stdin. It's a bit like "urlview" but uses less complicated regex and is faster. There is no third party software I use that is distributed via "curl|bash" and in practice I do not use curl or bash, however if I did I might use yy030 to extract any URLs from install.sh something like this curl https://example.com/install.sh|yy030 or curl https://example.com/install.sh > install.sh yy030 < install.sh Another filter, "yy073", turns a list of URLs into a simple web page. For example, curl https://example.com/install.sh|yy030|yy073 > 1.htm I can then open 1.htm in an HTML reader and select any file for download or processing by any program according to any file associations I choose, somewhat like "urlview". I do not use "fzf" or anything like that. yy030 and yy073 are small static binaries under 50k that compile in about 1 second. I also have a tiny script that downloads a URL received on stdin. For example, to download the third URL from install.sh to 1.tgz yy030 < install.sh|sed -n 3p|ftp0 1.tgz "ftp" means the client is tnftp "0" means stdin

stouset 1y ago

Yes! What I really want from something like this is sandboxing the install process to give me a guaranteed uninstall process.

hsbauauvhabzb 1y ago
Why would you possibly want to remove my software?
- ChocolateGod 1y ago
  This reminded me how if you wanted to remove something like cPanel back in the day your really only option was to just reinstall the whole OS.
mjmas 1y ago
tinycorelinux reinstalls its extensions into a tmpfs every boot which works nicely. (and you can have different lists of extensions that get loaded)

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?

shadowgovt 1y ago

Much of the reason `curl | bash` grew up in the Linux ecosystem is that "single binary that just runs" approach isn't really feasible (1) because the various distros themselves don't adhere to enough of a standard to support it. Windows and MacOS, being mono-vendor, have a sufficiently standardized configuration that install tooling that just layers a new application into your existing ecosystem is relatively straightforward: they're not worrying about what audio subsystem you installed, or what side of the systemd turf war your distro landed on, or which of three (four? five?) popular desktop environments you installed, or whether your `/dev` directory is fully-populated. There's one answer for the equivalent of all those questions on Mac and Win so shoving some random binary in there Just Works. Given the jungle that is the Linux ecosystem, that bash script is doing an awful lot of compatibility verification and alternatives selection to stand up the tool on your machine. And if what you mean is "I'd rather they hand me the binary blob and I just hook it up based on a manifest they also provided..." Most people do not want to do that level of configuration, not when there are two OS ecosystems out there that Just Work. They understandably want their Linux distro to Just Work too. (1) feasible traditionally. Projects like snap and flatpak take a page from the success Docker has had and bundle the executable with its dependencies so it no longer has to worry about what special snowflake your "home" distro is, it's carrying all the audio / system / whatever dependencies it relies upon with it. Mostly. And at the cost of having all these redundant tech stacks resident on disk and in memory and only consolidateable if two packages are children of the same parent image.

fouc 1y ago
I first encountered `curl | bash` in the macOS world, most specifically with installing the worst package manager ever, homebrew, which first came out in 2009. Since then it's spread. I call it the worst because it doesn't support installing specific versions of libraries, doesn't support downgrading, etc. It's basically hostile and forces you to constantly upgrade everything, which invariably leads to breaking a dependency and wasting time fixing that. These days I mostly use devbox / nix at the global level and mise (asdf compatible) at the project level.
- tghccxs 1y ago

mingus88 1y ago

My problem with it is that it encourages unsafe behavior. How many times will a novice user follow that pattern until some jerk on discord drops a curl|bash and gets hits IRC used to be a battlefield for these kinds of tricks and we have legit projects like homebrew training users it’s normal to raw dog arbitrary code direcly into your environment

SkiFire13 1y ago
What would you consider a safer behaviour for downloading programs from the internet?
- thewebguyd 1y ago
  Use your distro's package manager and repos first and foremost. Flatpak is also a viable alternative to distribution, and if enabled, comes along with some level of sandboxing at least. "Back in the day" we cloned the source code and compiled ourself instead of distributing binaries & install scripts. But yeah, the problem around curl | bash isn't the delivery method itself, it's the unsafe user behavior that generally comes along with it. It's the *nix equivalent of downloading an untrusted .exe from the net and running it, and there's no technical solution for educating users to be safe. Safer behavior IMO would be to continue to encourage the use of immutable distros (Fedora silverbue and others). RO /, user apps (mostly) sandboxed, and if you do need to run anything untrusted, it happens inside a distrobox container.
  - sim7c00 1y ago
    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...
  - hsbauauvhabzb 1y ago
    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.
  - 1y ago

nikisweeting 1y ago

This is always the beef that I've had with it. Particularly the lack of automatic updates and enforced immutable monotonic public version history. It leads to each program implementing its own non-standard self-updating logic instead of just relying on the system package managers. https://docs.sweeting.me/s/against-curl-sh https://docs.sweeting.me/s/against-curl-sh

IgorPartola 1y ago

This exactly. You never know what it will do. Will it simply check that you have Python and virtualenv and install everything into a single directory? Or will it hijack your system by adding trusted remote software repositories? Will it create new users? Open network ports? Install an old version of Java it needs? Replace system binaries for “better” ones? Install Docker? Operating systems already have standard ways of distributing software to end users. Use it! Sure maybe it takes you a little extra time to do a one off task of adding the ability to build Debian packages, RPM, etc. but at least your software will coexist nicely with everything else. Or if your software is such a prima-donna that it needs its own OS image, package it in a Docker container. But really, just stop trying to reinvent the wheel (literally).

1vuio0pswjnm7 1y ago

Many times a day both in scripts and interactively I use a small program I refer to as "yy030" that filters URLs from stdin. It's a bit like "urlview" but uses less complicated regex and is faster. There is no third party software I use that is distributed via "curl|bash" and in practice I do not use curl or bash, however if I did I might use yy030 to extract any URLs from install.sh something like this curl https://example.com/install.sh|yy030 or curl https://example.com/install.sh > install.sh yy030 < install.sh Another filter, "yy073", turns a list of URLs into a simple web page. For example, curl https://example.com/install.sh|yy030|yy073 > 1.htm I can then open 1.htm in an HTML reader and select any file for download or processing by any program according to any file associations I choose, somewhat like "urlview". I do not use "fzf" or anything like that. yy030 and yy073 are small static binaries under 50k that compile in about 1 second. I also have a tiny script that downloads a URL received on stdin. For example, to download the third URL from install.sh to 1.tgz yy030 < install.sh|sed -n 3p|ftp0 1.tgz "ftp" means the client is tnftp "0" means stdin