Hacker News Reader

Hacker News

Comment by walrus01 | Hacker News Reader

Parent Full thread

walrus01

This looks great as a software project. And a good alternative to Nano.

But from the website: "curl https://getmic.ro | bash"

NO!

We need to stop getting people comfortable with the idea of just curling random stuff into their shell.

Even worse is software that suggests you sudo curl it into bash. What could possibly go wrong?

Download and build it yourself. Or download and install a packaged .deb or .rpm or whatever is the equivalent for your platform.

Do not just blindly curl into your shell things coming from people you don't know and trust to the level that they are personal friends and you would loan them your house keys or your car.

View on HN

Why is this more dangerous than installing a deb, which can also run arbitrary code as root?

a .deb at least went through some cursory level of examination by the people who downloaded the source, built it and are authorized by the debian project to submit new .deb files to the debian package servers.

not just any random person can submit a .deb and have it go live on the gpg-key authenticated debian mirrors.

https://wiki.debian.org/Packaging

https://www.debian.org/doc/manuals/debmake-doc/index.en.html

curl into bash can be as quick as "ooh look shiny new thing on website, let's copy/paste this string of text into my shell"

I agree that debs that were audited and distributed in the package manager are better in that way. I guess my objection is that "curl https://getmic.ro | bash" often gets a hostile reaction here on HN whereas "wget https://github.com/zyedidia/micro/releases/download/v2.0.10/... && dpkg -i micro-2.0.10-amd64.deb" does not.

The latter absolutely should get just as hostile a reaction. The only thing it provides you over the former is that it at least guarantees you that the author went to the trouble of creating a deb.

Actually, it should probably get even more hostile a reaction, since installing it that way usually means you won't get any updates for it. If you absolutely must install software from a (trusted) source other than your distribution, adding a source and then using `apt` is the way to go.

If you need to install from the author's site, that means that there is no Deb available in the official repos, or that it's outdated. In both cases, you end up installing something that the author compiled.

The reality is you need to install a random PPA or download a random deb from the author's website, github, etc. because the debian release is woefully out of date. So you're back to installing random binaries again.

If you need the latest available versions of the software you use, you should probably use a distribution that has that as a goal. Debian is built with the intention of providing stability, under the assumption that most of its users can afford to go a couple of years without feature updates in the software they use.

It is more about streamlined process of package management to which Linux users are used. At least with deb/rpm package I understand where package stuff goes and how to uninstall it (of course, packager could mess up this with arbitrary install scripts).

And each 'curl https://' packager has its own idea where his software should be installed. And many of them are not even providing automated way to delete their application.

Since the script comes from GitHub repo, and the source is also on the repo, isn't building the source the same as getting the shell script and running it? I mean if one is compromised, the other might be compromised too.

Literally every time somebody on HN has to write a comment shaming for curling into bash. We get it. You should download the script, inspect it, and then execute it.

This is not the same as "sudo curl https://getsomefile.ro | bash". That is dangerous. While I understand your point, it's really not the same thing. This checks your system for its architecture and then downloads the correct binary to the directory you run it from. I know this because it's very easy to copy the URL, drop it in your browser and read the script. That's what I did before running it. And it is certainly safer than adding some random software repository which is what a lot of instructions suggest.

I suppose using a package managers that random people can commit stuff into would be a no go for you too.

I think complaining about streamlined remote script execution is just being pedantic.

If you're so worried, wget to see and run.

Reply on news.ycombinator.com