Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Audacity of Piping Curl to Bash

yotam.net

Post reply on HN
Print view View original

31–40 of 111 posts

Re: The Audacity of Piping Curl to Bash

#31

Post by superkuh »

mustache_kimono wrote: post #15
superkuh wrote: post #4

Not just applications. Entire programming languages like Rust depend on this to install the compiler (rustup, since rustc changes too fast for anything but the most rolling of distros to keep up).

> Entire programming languages like Rust depend on this to install the compiler And it works! For people who have to stay on top of language changes (not everyone), who are on a wonky platform or that doesn't update quickly enough, this is actually a pretty okay method. And they do also offer alternative methods: https://rust-lang.github.io/rustup/installation/other.html Here, the "You know what they should be doing.…

>For people who have to stay on top of language changes (not everyone)

Or anyone that wants to try out the latest "$something but in rust" and tries to compile it.

>who are on a wonky platform or that doesn't update quickly enough,

ie, the vast majority of people so I question the word "wonky" here.

>This may have once been true, but isn't really anymore.

It's still true in my experience. But then again, Rust does change really fast. Maybe they fixed their entire bleeding edge demographic in the last couple weeks and now people refrain from using $latest features that don't work in rustc from 3 months ago.

Re: The Audacity of Piping Curl to Bash

#32

Post by kybernetikos »

derefr wrote: post #22
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some ki…

> devs either properly package their apps, or don't release them at all.

There's still no widely accepted answer for what 'properly package their apps' looks like. You could want snaps or appimages or a flatpak, or rpms or debs or docker containers or nix flakes or cargo crates or python virtual environments or jars or javawebstarts or portable windows executables or windows msis or webasm packages or web pages ... there's an impossible profusion that it's currently unreasonable to expect devs (many of whom are working for free) to support more than a couple of.

If there were a single solution that worked in almost all cases and platforms, didn't put unreasonable constraints on packagers and was widely adopted, then it might be somewhat reasonable to expect devs to support it, but that's far from the world we live in. The closest to that (despite its real problems) is probably piping a curl to a bash script...

Re: The Audacity of Piping Curl to Bash

#33

Post by rich_sasha »

gorjusborg wrote: post #28

I post this every time this topic comes up. Piping from the internet into your shell is a bad idea. https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

I used to think that.

But is it really that much worse than `pip install` random stuff? Or Homebrew, or Linux package managers - it's not like these things get audited.

Re: The Audacity of Piping Curl to Bash

#34

Post by bombcar »

mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

Even if omz had a package-managed package, it would do the basic curl|bash itself the moment it was installed, to update itself. Technically it's git and things, but that's all the curl|bash does anyway.

Re: The Audacity of Piping Curl to Bash

#35

Post by mdaniel »

uuddlrlrbaba wrote: post #21

Dive into the details of what "clean" packaging entails, how much practices differs between distributions, how many distributions there are, how each dependency also needs to be packaged and maintained across upgrades... And you'll quickly see why projects say fsck it -- we support installation via curl | bash. go and package it yourself it you want to. It really highlights the need for a broadly adopted "homebrew fo…

> "homebrew for linux" type package manager that could safely manage software without conflicting with OS packages.

As someone who uses Homebrew for Linux, I can say that "without conflicting with OS packages" cuts both ways: fine, I get more modern stuff than apt could imagine, but having to monkey with the LD_LIBRARY_PATH or -Wl,-rpath over and over gets old real fast. I have no idea why they tried to be so cute putting things in a stupid directory (/home/linuxbrew/.linuxbrew) instead of /usr/local like they did with Homebrew for Mac (err, not the arm64 version, where they went back to /opt/homebrew for whoknowswhy)

Re: The Audacity of Piping Curl to Bash

#36

Post by daitangio »

bash installer are neat, fast and dirty. They shines inside a Dockerfile, because enable to install not-yet-packaged software.

To avoid regret their launch, I enabled sudo to ask me a password, to avoid some sudo malicious command in the wild destroying my box or wiping my nas drives...who knows? :)

Re: The Audacity of Piping Curl to Bash

#37

Post by umvi »

> For the love of god, why do I still have programs on Linux that don’t use xdg directories?

Because a lot of devs have never heard of it? I'm a linux app dev of <10 years and I've never heard of xdg until this post. I just assumed dotfiles in the home directory were still the de facto standard...

Re: The Audacity of Piping Curl to Bash

#38

Post by revolvingocelot »

simiones wrote: post #9

This seems almost like a misunderstanding of what is the role of an installer, especially for something like oh my zsh. The author is complaining that it takes over their zsh configuration, when in fact that is obviously the whole point of the installer. An installer isn't simply there to copy a program to your system. It's there to copy files to your system and then modify your system so that it is ready to use the…

>An installer [... is] there to copy files to your system and then modify your system so that it is ready to use the new program to the deepest level that makes sense

Sure, but what's the corresponding step in the zsh "install"? Looks like copying over their ~/.zshrc. The "install" script could have chosen to clone the git repo, copy the file, then print "all done! run 'zsh' to start your new shell!' or whatever

Re: The Audacity of Piping Curl to Bash

#39

Post by manv1 »

Really, the risk here is that the install is going to do something unfortunate, like delete everything in your filesystem because you have a space in your home directory name or cause problems because your .profile didn't end with a CR and it blindly appended it's own stuff to it.

I'm not sure how package managers prevent this sort of issue, but in general running shell scripts as root (and it probably needs to run as root) is a bad thing.

Re: The Audacity of Piping Curl to Bash

#40

Post by dllthomas »

hprotagonist wrote: post #12

curl ... | bash is the moral equivalent of {npm, pip, nuget, ...} install and i really don't understand the folderol around that. In both cases, you can alter the command slightly to instead download the payload without executing it and inspect it first, if you wish. In both cases, you're ultimately going to either audit and then execute or just execute code from Somewhere Else. This is true for distro package manage…

If curl dies early, bash might be executing a truncated script. Arbitrarily truncated bash scripts are often valid bash scripts that do things you don't want.
Post reply on HN