Hacker News Reader

Comment by IshKebab | Hacker News Reader

> Even apps that could easily be built into a single binary use these odd installation methods.

Yeah because the curl bash script can deal with automatically selecting the right binary (even on Mac) and adding it to your PATH.

> And while Flatpak gets a lot of criticism, I honestly think it's far better than these `script| bash` methods.

I agree but does Flatpak actually work for CLI tools (which is where I see most use of curl-bash). E.g. could I install Rust using Flatpak? My understanding was it's more suited for sandboxed GUI apps.

View on HN

> I agree but does Flatpak actually work for CLI tools (which is where I see most use of curl-bash). E.g. could I install Rust using Flatpak? My understanding was it's more suited for sandboxed GUI apps.

Distrobox is basically flatpak for CLI apps. Not exactly, but it accomplishes a similar goal.

Doesn't it use Docker? Fine for trying stuff out on different distros but there's no way I want Docker as a normal installation process.

Docker is what you use if you've failed to do it the right way.

No. It is absolutely ridiculous to suggest that one must read some unknown script just for the simple task of adding a binary to the directory on PATH. Unless, of course, you're the type of person who just runs any script without verification.

Furthermore, for files installed 'automatically' like that, it's nearly impossible to remember what was done and where. This means that to remove it, you have to find and read 'that specific version' of the script you ran, and then delete the files. It's not like the script is always in a place with a persistent history, like a git repository. Good luck with that.

Yeah uninstallation is a flaw, but what alternative are you suggesting?

And yes I am the type of person that uses heuristics to trust what software to run. You aren't magically safer if you audit the install script and not the actual binary.

The smaller the attack surface, the better. There is no need to expand it unnecessarily. By your logic, we shouldn't even use the binaries provided by the official package manager, because they also cannot be trusted.

We are talking about the dangers of the installation method. Not the program itself.

> We are talking about the dangers of the installation method. Not the program itself.

It only makes sense to separate them if you install the program and then never run it which is obviously ridiculous.

> There is no need to expand it unnecessarily.

I agree, but it is necessary because there aren't any good alternatives.

Also it is very minimal additional risk. If it wasn't we'd see it used as an attack method and as far as I know that has yet to happen once.

Reply on news.ycombinator.com