"curl | sh" certainly feels wrong, but in the end, even if you download and read the script before running commands, let's be real: you are going to run a binary that you didn't inspect.
Not saying you shouldn't check your scripts, I usually do, I like to know where the files are going in case the installer messes up, but the risks tend to be overstated compared to running the executable itself.
that's a fair point, but the script doesn't do much, and this method should not be normalized. i downloaded the release manually, unpacked it, and moved the binary into ~/bin/
what's left is adding the init command to the shell init script.
and it turns out that this is included as an alternate way to install in the repo README.
i really don't see the point of the install script. the verification it offers is of no value because if the repo is compromised then the install script could be compromised too.
What if this project offered binaries from GitHub releases instead? How do you read those?
It's more realistic to decide if you trust the source, GitHub user yamafaktory in this case. Then you can ensure that your method of download uses TLS.
It already does. The releases page has prebuilt binaries for four targets plus a SHA256SUMS file. You can download the tarball straight from GitHub over TLS, verify it against the checksums, and run it. No script involved.
Not saying you shouldn't check your scripts, I usually do, I like to know where the files are going in case the installer messes up, but the risks tend to be overstated compared to running the executable itself.