Why do you think your opinion is more valuable than that to which you reply?

For what it's worth, I can rattle off many more project names at random in 30s, and odds are they'll all have installation methods that aren't curl-pipe-shell, there are just so many more of them.

Please read what I wrote more carefully: I wasn't giving an opinion (other than the word "tedious"). I was pointing out the fact that there are large numbers of experienced software engineers on both sides of this argument, and hence it isn't an argument that can be settled, or even helpfully contributed to, by individuals giving their opinions. It's got to the point where it's more like politics or religion or something.

I for one think that this individual opinion has value under this post as a PSA to people who might not otherwise give the command a second thought, regardless of the conclusion they take away.

"a bunch of folks do something insecure" does not speak argument.

The argument is that it is insecure. Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." and get your company ssh keys. There's no reason rust, brew and all the rest can't provide a Download page with a checksum. They choose not to, like this project chose not to, because it doesn't look as sexy.

It's really silly.

Sure you can, but there's always going to be trust somewhere. I trust that the curl | bash examples I see are from reputable sources, and I trust their infra as much as someone else's to be safe (https protects MITM attacks). NixOS is a cool example of complete package transparency with their binary cache, if your expressions don't evaluate the same as theirs you'll build from source.

But really, curl | bash isn't the end of the world.

If they do it against a github url they also have the security of github behind you, because you can't differentiate on user agent there, which seems to be the commonly argued pitfall. Or other ways to detect you're not a browser, on a hosted platform you have someone else's security team behind your back.

If someone has pulled off a sophisticated enough attack to intercept your http curl of the script and inject a malicious version, why can't they also intercept your brower http requests for the download page and inject different html that gives a good hash/checksum of the malicious script?

Going even further, what is stopping a malicious attack on the package source itself--like someone gaining control of the package source and committing a malicious version (as NPM, pypi and other registries have seen)?

The point is, "use your package manager" is not any better in the grand scheme of things than blindly curling and executing a script. Neither option is perfectly secure.

No, the concern is not your computer is compromised. Yours is a low-value target, sorry.

It's their http server, or a machine that feeds that http server, which is a good target for a compromise. Injecting a little bit of malicious code that steals something, or installs a fileless piece of malware, would bring massive benefits to the perpetrator, even if the exploit is short-lived.

That shell script should be a zip (gzip, xz) file, with a sha256 hash of it published on a different, separately hosted resource.

Maybe we should provide an utility that just does that in one command. It could even be a shell script...

Realistically a poisoned ARP or DNS attack that redirects your machine's traffic to the attacker's server, both for the download and the download page, is something to be concerned about. This only requires someone to have access to your local network, not to your machine. It could be as innocent as working at a coffee shop from their wifi network and an attacker being on it too...

curl validates the TLS certificate by default, it will fail in your scenario unless you pass -k. dev TLD requires https on all connections

Why can’t the downloaded binary package do the exact same thing? Or do you decompile and go through those as well?

It could, but I can trust that no individual stepped in the middle of that process.

I trust Rust to not put such a thing in their binary. I do not trust an arbitrary man in the middle, and it's trivial to modify a shell script.

Without a checksum, I can't ensure the binary im piping through the shell is the binary they posted and built. Anyone can step in, modify a few lines, and get access to a large part of my system. The barrier to entry to add such capability to arbitrary binaries is outrageously high.

Install scripts are usually hosted on GitHub/etc and changes are clearly tracked. Compiled binaries are untracked and do not offer the same guarantees. I would trust the script more than a binary that could’ve been modified anywhere along the build process.

Not everyone uses Linux, and not every package can be audited by repo devs. It’s simply not scalable.

> Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..."

If you can inject that breaking TLS which secures everything on the internet, why can't you inject your own checksum on the "download page"?

Checksums and the binaries can be stored in different places for redundancy.

Trusting it because other people trust it for no apparent reason does not seem like a very compelling argument. For all I know, the Rust and homebrew communities know squat about how to securely deliver binaries.

I wish I could upvote da39a3ee's comment 100 more times. I hate condescending know it all people, and da39a3ee stated this way more eloquently then I would have.

Have you read the Hacker News Guidelines, particularly the section labeled "In Comments"? If you haven't, I suggest that you should.

Do you mean for the original comment complaining about the script?

> Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

> Avoid unrelated controversies, generic tangents, and internet tropes.

> Please don't post shallow dismissals, especially of other people's work.

> Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.