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

41–50 of 111 posts

Re: The Audacity of Piping Curl to Bash

#41

Post by steveklabnik »

sjmulder wrote: post #13

Another downside of these scripts is that they tend to make changes to your user or machine configuration, something which is tolerated from Windows installers but a big no-no for me. E.g. I believe Cargo edits .profile to add its path and Teams makes itself start at login (!). For reasons such as these, but also things like telemetry configuration defaults and clean uninstalling, I prefer using a package manager. In…

Cargo does not. Rustup’s installer does, by default. It informs you of this before it does so, and you can ask it to not if you’d prefer.

Re: The Audacity of Piping Curl to Bash

#42

Post by user3939382 »

mjw1007 wrote: post #17
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…

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind. I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

> a reliable way to uninstall the program, without leaving any mess behind

cc: Anyone working on macOS

Re: The Audacity of Piping Curl to Bash

#43

Post by Cyberdog »

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…

This is kind of my take on it. As gross as I find pipe-to-shell installers to be instinctually, I can't really think of any objections I have about them which don't apply to just grabbing a package from MacPorts, save for one: MacPorts gives me a unified interface for listing and uninstalling that software after it's installed that I don't get from ad hoc installers. But in terms of the common complaints like security, it's pretty much the same - it's not like I'm auditing the source or patches of all the software I'm installing via MacPorts either.

Re: The Audacity of Piping Curl to Bash

#44

Post by Joker_vD »

> why do I still have programs on Linux that don’t use xdg directories?

Because there are Linux developers who never heard of XDG and just put their stuff wherever. And since ignoring XDG doesn't makes your application completely unusable, they have pretty much zero incentive to learn about it. Crazy world, isn't it?

Re: The Audacity of Piping Curl to Bash

#45

Post by mustache_kimono »

superkuh wrote: post #31
mustache_kimono wrote: post #15

Earlier quoted context omitted.

> 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 ch…

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

This is kinda true. I think a smallish demo re: who usually downloads a compiler, but it happens. I had a very sophisticated user/dev file a bug about how my software wouldn't compile. Turns out re: compiling from source they downloaded an old version of rustc from their distro's repos, instead of following my instructions, and my new sources wouldn't compile.

Now this was user error. But it happens. Just re this compiler error it was a good change and an easy fix. I stick to a MSRV now.

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

The vast majority of people aren't downloading compilers.

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

Price of using a non-dead language I'm afraid? You and I don't have to worry about the current patois of Latin or ancient Greek either? Remember -- the problem is I create something new, which compiles with a newer version of the compiler, you download the sources and compile, and you get an error because you have an older version of the compiler. This happens in every ecosystem, whether its C, Python or Rust.

If you're argument to me/the kids is: It should be old and nothing should ever change, I'm not sure that's a winner.

Re: The Audacity of Piping Curl to Bash

#46

Post by Brian_K_White »

mustache_kimono wrote: post #30
derefr wrote: post #22

Earlier quoted context omitted.

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

> "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he sho…

Yet somehow as a developer I have no problem at all realising that it is user-hostile to take liberties with their system.

It's violating trust and I have no need to do it in order to provide, even to install, a piece of software.

Re: The Audacity of Piping Curl to Bash

#47

Post by irusensei »

ragingrobot wrote: post #2

Quite a few applications do this. For something like the mentioned oh-my-zsh, it can be safely assumed the user is not a novice in most cases. Having to install in this manner may in fact deter the user, as they'd be suspicious. A well written README would be the better route.

Not always. Lots of programs that do this might be targeted for intermediate users. Brew is the first thing that comes to mind.

I seem to recall a case of a certain application that uses curl to bash to install docker, docker-compose and finally create its containers. The problem lies with the fact that said script committed the mistakes of trying to pull docker from Docker repositories instead of using the one from the distro and also thinking $distro_based_on_ubuntu (I think it was Mint) is Ubuntu. A mess was made and I had to help some guy to fix it.

Re: The Audacity of Piping Curl to Bash

#48

Post by denton-scratch »

mustache_kimono wrote: post #30
derefr wrote: post #22

Earlier quoted context omitted.

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

> "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he sho…

> "You're getting all this stuff for free."

Of course.

Part of packaging something, and then releasing it through a distro's package manager, is that it goes through the distro's release process; someone reviews it. It becomes part of the distro. In particular, if it goes into something like Debian's "main" repository, I'm inclined to trust it almost as much as I trust the core OS release.

I'm not going to man battlements anywhere over this kind of thing; but I'm not going to execute arbitrary shell scripts downloaded from the internet without reviewing them; and 600 lines of shell-script is more than I want to review, unless I'm super-motivated. If the only way of installing a package is Docker (which I don't care for) or wildcat script, and that package has no maintainer for my chosen distro; that's fine, and I'm not going to beat up the developer. It's not his fault, nor his responsibility.

So instead I generally look for an alternative package that's shipped by my distro. I don't keep a record of all the wildcat software installed on my systems, because there usually isn't any, and my package manager knows exactly what's installed.

Re: The Audacity of Piping Curl to Bash

#49

Post by Brian_K_White »

rich_sasha wrote: post #33
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.

Yes it is really that much worse. Homebrew in particular has always been a terrible example itself. Yes a linux package manager is entirely different.

Re: The Audacity of Piping Curl to Bash

#50

Post by dagmx »

user3939382 wrote: post #42
mjw1007 wrote: post #17

Earlier quoted context omitted.

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind. I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

> a reliable way to uninstall the program, without leaving any mess behind cc: Anyone working on macOS

Uninstalling macOS apps is usually as simple as removing the app bundle.
Post reply on HN