Why? If it's over TLS you can trust it's being served by the owner of the website. You're having to trust the person who wrote the script anyway. And before anyone says "I'm going to inspect the shell script before I run it", do also note that its purpose is to download and run binaries that you are never going to inspect.
The other thing to be careful about is that the script is written in a way that a truncated script has no effect. This is because sh will execute the stdin line-by-line as it reads it, so if the download fails in the middle of a line the downloaded fragment of that line will be executed.
It can be the difference between `rm -rf ~/.cache/foo` and `rm -rf ~/`
The standard way to solve this problem is to put the entire script inside a function, invoke that function in the last line of the script (as the only other top-level statement other than the function definition), and name it in such a way that substrings of the name are unlikely to map to anything that already exists. Note that the bun.sh script does not do this, but also from a quick glance the only thing that could noticeably go wrong is this line:
rmdir $bin_dir/bun-${target}
A truncated download could make it run `rmdir $bin_dir` instead, in which case it'll end up deleting ~/.bun instead of ~/.bun/bin/bun-${target}, which is probably not a big deal.
IMO the main problem is that it isn't clear how updates will work. Some of the curl-to-bash scripts don't do anything in regards to updates at all, some add a PPA/similar on ubuntu/debian/fedora/etc.
It'd be nice to know what and how I should manage updates.
Even if you do compile the kernel yourself, do you really own your OS if you haven't compiled the compiler yourself? Did you use a pre-built compiler binary to compile the compiler?
Now we're getting to the real questions in life. :)
(Incidentally, this is probably the most fundamental software supply chain attack vector - manipulate the compiler binary used to compile the compiler used to compile the kernel and userspace. The attack payload would never appear in any sources, but would always be present in binaries.)
You could add additional security to the process by first validating some cryptographic signature or verifying that the downloaded content's hash matches one that the author published.
Both of those just push the overall security a bit down the line, but both are ultimately not completely safe. The only truly safe action to take is to not download it at all.
