286
Developers: I will never ever do that, no one should ever do that, and you should be ashamed for guiding people to. I get that you want to make things easy for end users, but at least exercise some bare minimum common sense.
The worst part is that bun is just a single binary, so the install script is bloody pointless.
Bonus mildly infuriating is the mere existence of the .sh TLD.
Edit b/c I'm not going to answer the same goddamned questions 100 times from people who blindly copy/paste the question from StackOverflow into their code/terminal:
WhY iS ThaT woRSe thAn jUst DoWnlOADing a BinAary???
- Downloading the compiled binary from the release page (if you don't want to build yourself) has been a way to acquire software since shortly after the dawn of time. You already know what you're getting yourself into
- There are SHA256 checksums of each binary file available in each release on Github. You can confirm the binary was not tampered with by comparing a locally computed checksum to the value in the release's checksums file.
- Binaries can also be signed (not that signing keys have never leaked, but it's still one step in the chain of trust)
- The install script they're telling you to pipe is not hosted on Github. A misconfigured / compromised server can allow a bad actor to tamper with the install script that gets piped directly into your shell. The domain could also lapse and be re-registered by a bad actor to point to a malicious script. Really, there's lots of things that can go wrong with that.
The point is that it is bad practice to just pipe a script to be directly executed in your shell. Developers should not normalize that bad practice.
Would you prefere
?
I mean, how about:
~/.local/binI think you missed the point.
Why is that safer/better? That binary can do anything a shell script can, and it’s a lot harder to inspect.
The point is that it is bad practice to just pipe a script to be directly executed in your shell. Developers should not normalize that bad practice
If you trust them enough to use their binary, why don't you trust them enough to run their install scripts as well?
Trust and security aren't just about protecting from malice, but also mistakes.
For example, AUR packages are basically install scripts, and there have been a few that have done crazy things like delete a users /bin — not out of any malice, but rather simple human error.
Binaries are going to be much, much less prone to these mistakes because they are in languages the creators have more experience with, and are comfortable in. Just because I trust someone to write code that runs on my computer, doesn't mean I trust them to write an install script, especially given how many footguns bash has.
Steam once deleted someone's home directory.
How do you know the script hasnt been compromised? Is every user competent enough to evaluate it to ensure its safe to run?
Using package managers to handle this provides a couple things: First: most package manager have builtin mechanisms to ensure the binary is unmodified Second: they provide a third party validating them.
You don't, same as you don't know if the binary has been compromised, just like when a npm package deleted files for russian users. I get that running scripts from the internet without looking at them first to understand what they do is not secure, but downloading and running anything from the internet is coupled with some amount of risk. How do you know that you won't be mining crypto currency in addition to the original purpose of the binary? You don't unless you read the source code.
It all comes down to if you trust the provider or not. Personally, if I trust them enough to run binary files on my computer, I trust them enough to use their scripts for installation. I don't agree that something is more unsafe just because it is a script.
Not everything is provided with a package manager, and not everything is up to update with the OS provided package manager. I agree that one should ideally use a package manager with third party validation if that is an option.
Yes. thats precisely the problem we're pointing out to you. if you're going to provide software over the internet provide a proper package with checksum validation. its not hard, stop providing bash scripts.
I just took NPM as an example of code that was trusted doing shady things. And I know what checksums are and how they work. What I meant is that the developer providing you with the checksum has put in malicious code in the binary. You don't know. (I don't think that is very likley but it all boils down to trust.)
No, I don't think I am?
And I am saying that it is not that big of a problem.
we all know what you meant. you're just incorrect, your conflating multiple different types of attacks and asserting the one that is easiest to resolve is an equivalent problem. shrug
many devs i've encountered in the wild (FANG/startups/randomly) can barely sort a list without causing problems. so now we have people hosting multiple servers they probably didn't configure correctly. meaning instead of a few centralized repositories we need to secure we now have to trust these individual people have enough technical know how to safely host such a setup.
thats the problem with these setups. its not the developer being a bad actor we're worried about, its the systems they've setup to serve these scripts. with checksums and side channels its easy to validate the resulting binary. which can effectively nips any issues with a compromised repository.