[qbasic_forever]

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.

[nine_k]

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...

[qbasic_forever]

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...

[moondev]

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