Hacker News new | ask | show | jobs
by KeyboardFire 2868 days ago
It makes me a little uncomfortable that they're using curl|bash for something as simple as "put this 10-line script somewhere in your $PATH," especially when the script involves sudo (to move into /usr/local/bin). Sure, it's easy to inspect the script and see that it's not doing anything malicious, but it makes install processes like this, where it'd be incredibly easy to, seem normal.
3 comments

Yeah, and it's not even getting the code from an official source; it's coming from a random bit.ly link [created by a contributor][1].

I've [submitted a PR][2] to inline the install script in the README.

[1]: https://github.com/thisredone/rb/pull/5

[2]: https://github.com/thisredone/rb/pull/8

Thanks, merged
I didn't even see that. I followed the directions in the top section ("Clone this repo and copy the rb file to somewhere in your path (or just copy and paste the above).") (I did have to chmod +x)

That said, brew install foo is a normal part of many development workflows, which essentially just curls a file from someone else's git repo.

It's such a common pattern too. I can't believe people are still doing this and it's generally acceptable.
I mean, if you think about it, any time you run any installer, whether via brew install, apt-get install, or an .exe or .msi, you're effectively running someone else's unknown code on your system, often as a superuser (e.g. with sudo apt-get install). Is there a significant difference here? At least in this case you could potentially download the shell file and read it before you run it, unlike with a binary executable.

Am I way off base here?

Some context on why curl pipe bash is a bad idea: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Most recent discussion: https://news.ycombinator.com/item?id=17636032