Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

Pipe the script to cat before you pipe it to sh and take a look. It's downloading an executable to ~/.local/bin. If that's not your preference, there are many other options for obtaining the software, via your distribution or manually. I feel the backlash to this pattern is pretty overblown. They're not attempting to hide anything, just make the common case convenient.


A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.


Probably the biggest problem with the `curl | sh` approach is it bypasses package maintainers. I agree it's really no different than if you compiled malicious code yourself (or pulled in a 3rd party bin repository). However, one of the functions of a package maintainer is finding/being notified of security issues.

I'm thinking of the recent xz attack. Imagine how bad that would have been if xz was commonly installed via `curl | sh`.

All this is to say `curl | sh` is probably fine if the org is reputable, however, you should be having second thoughts if this is a repo ran with a bus factor of 1.


Yet the xz attack specifically targeted the packages and nothing else. And it worked, to a point. All I’m saying package maintainers are human and can’t detect everything.


I think for most it's not a security issue but a system maintainence one. Where does the script install what?


Sure, but that convenience will come to bite you later. What happens when you want to update it?

Their full install docs is like 5 lines of code so it is much preferred to do it that way. Every distribution is different. The ideal install here would be to add a unique apt repo for zed and then it becomes part of my normal update process. Updating a binary in a directory is not the end of the world... but I would prefer to know that upfront versus needing to hunt down where it was placed in order to do the updates.

edit its 4 lines. seeing this is much preferred to parsing a bash script that is intended to support all distributions:

    wget https://zed.dev/api/releases/stable/latest/zed-linux-x86_64.tar.gz
    mkdir -p ~/.local
    tar -xvf zed-linux-x86_64.tar.gz -C ~/.local
    ln -sf ~/.local/bin/zed ~/.local/zed.app/bin/zed


Suggesting that users install software outside of official repos isn't more convenient than using a repo and standard package management tools. As soon as there's an update, you'll learn exactly why that is the case.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: