Hacker News Reader

Comment by tsukikage | Hacker News Reader

"Installing: curl https://get.please.build | bash"

...one can stop reading there: this product is not aimed at this community.

I don’t think this is a fair reason to write the tool off. They support Homebrew, and I’m sure will add other install methods in the future. Piping to bash is no worse than clicking “yes” on every step of an install wizard.

The alternative is not “install wizard”, it is either “here is a deb file with no post* scripts” or “here is a tar.gz, extract it anywhere and add symlink”

Both of those are vastly safer, because they do not require root privileges, and guarantee to uninstall cleanly.

This. Simply the decision to eschew standard package management already says unpleasant things about their approach to integrating with my environment, or in whatever it is the installation does being reversible using standard tools. "Install wizards" do indeed have exactly the same issue, which is why those are also terrible.

Often these "pipe to Sh scripts" support --help and a variety of configuration options anyway. The benefit of a script over a binary installer at least is that you can inspect the script before running it!

Have you inspected one of these scripts? What have you found? (I've tried it a few times and haven't felt like I learned anything meaningful from doing so.)

I almost always inspect these kinds of scripts before running, more out of curiosity than anything, but also so that I know its not going to do that so stupid that even I can see it's stupid. Usually you can just pipe to `cat`, which is super low effort to do.

I've occasionally seen scripts that install some other application where it was not clear that it was a dependency and there was no heads up to the user that this was going to happen: that kind of behavior makes me more distrustful of the author, so there's a useful signal there.

Most scripts like this seem to amount to "configuration defaults + cli completions installation". To that end, I find looking at them useful because it gives me a sense of the expectations of the tooling and hints at where I might find things if I need to go debugging later.

When they are provided by the same entity as the program you wish to run, I don't see how it's significantly more risky to run these scripts than running the application code itself with the active user's permissions. Still, if there was something, by glancing at the script, you have half a chance of seeing it. If there's something there that doesn't make sense, that's both a "proceed with caution" and a learning opportunity.

cat to terminal is kinda not enough. I can own you very easily if you do just that and think you've seen all the code that will be executed.

Save to file, and read the file in the editor.

It’s not really intended as a defense against being owned per se, it’s more about knowing what’s going on and getting an additional signal about the risk profile (not just from maliciousness) of the thing I’m about to run.

That said, I generally pipe to file and cat the file, yes, if only because it somehow feels wrong to download it twice.

I understand, but cating the saved file or printing from pipe to the terminal directly has identical issues. Terminal ANSI escape sequences are interpreted either way.

Great point. Thank you.

I did!

The usual annoying thing is the automated package install. I have not looked at this particular package, but in the past, I have seen:

- installing specific gcc version and making it system-default.

- installing “virtualbox” packages - this was the worst, as the machine had a few KVM VMs running at the same time, and KVM and VirtualBox cannot run at the same time.

In general, I now stay away from every install script, and if I cannot, then I run it in docker container. Life is short, I do not want to spend it fixing my primary workstation.

(And I examine postinst scripts in deb files too, but those are usually much more boring)

Yuck, those are some really badly-behaved installers.

Yes, plenty of times. Usually I find that they do what you would expect them to do: set up a bunch of parameters like an installation prefix, and then copy files around. They also handle user input options and maybe prompt for some stuff.

This kind of dismissive, even arrogant, comment has no place in this community.

Do you think clicking "yes" on an installer is any more secure?

Yes. For starters, it's much harder to suffer disastrous consequences from running truncated command due to terminated network connection when running an installer.

This is easily rectified by script authors by adding a main function invoked at the end. At a certain point, the argument simply becomes "executing arbitrary code is potentially dangerous", which is trivially true, and also not a helpful security posture for anyone who wants to use their computer pragmatically.

Theoretically yes, it is all turing complete at the nd. Practically no, it is the matter of established conventions.

For example, most interactive installers I have seen prompt for install location, and write minimal amount of files outside of it. The chance that they break your system is pretty low.

At the same time, many |bash scrips like to install system-wide packages, or use pip as root, or other potentially breaking things. And they do not ask you before installing this, and often auto-confirm, too.

Why? I pragmatically use my computer with packages my distro offers me. When I download something from untrusted sources, I do take a quick look at what it is before executing it. It still is dangerous since I'm not able to spend time on verifying every single line of it, but it's up to me to decide whether that's an acceptable risk or not. All perfectly pragmatic.

I'm not a kind of person who's on a crusade against curling into bash, but I never do that myself because it feels dirty. It gives me no advantages and makes me unable to even take a quick look to reassure myself that things at least look like what I'd expect them to be.

I also read scripts from the user repositories on my distro. It’s perfectly pragmatic for us because we understand shell scripts and system administration. It makes me feel better too. But I would never tell someone to avoid installing developer tooling simply because it pipes curl to bash. It’s not pragmatic to tell a new developer they need to learn to be a sysadmin before installing homebrew.

That's a strawman though. Nobody wants to tell that to new developers. This is all about conventions and normalizing bad behaviors. New developers should avoid piping curl to bash and explicitly download files instead because when they eventually will become experienced enough to inspect those files they will start doing it naturally.

Good practices are rarely black and white, they're often there to influence how you think about stuff and what habits you develop.

Reply on news.ycombinator.com