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

  1. 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
  2. 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.
  3. Binaries can also be signed (not that signing keys have never leaked, but it’s still one step in the chain of trust)
  4. 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.

  • uranibaba@lemmy.worldEnglish
    4·
    2 days ago

    How do you know the script hasnt been compromised?

    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.

    package manager

    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.

    • jatone@lemmy.dbzer0.comEnglish
      11·
      2 days ago
      1. no one is talking about NPM libraries. we’re talking about released packages.
      2. you absolutely can ensure a binary hasnt been tampered with. its called checksumming.
      3. you’re confusing MITM attacks with supply chain attacks. MITM attacks are far easier to pull off.

      Not everything is provided with a package manager

      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.

      • uranibaba@lemmy.worldEnglish
        2·
        2 days ago

        no one is talking about NPM libraries. we’re talking about released packages. you absolutely can ensure a binary hasnt been tampered with. its called checksumming.

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

        you’re confusing MITM attacks with supply chain attacks. MITM attacks are far easier to pull off.

        No, I don’t think I am?

        Yes. thats precisely the problem we’re pointing out to you.

        And I am saying that it is not that big of a problem.

        • jatone@lemmy.dbzer0.comEnglish
          11·
          2 days ago

          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

          1. if the developer of the application is writing malware, its malware end of story. its usually discovered rapidly and people avoid it.
          2. supply chain attacks are harder to achieve (i.e. uploading a tainted binary to a software repository)
          3. curling a shell script is pretty much the easiest target. you have a bunch of randomly setup servers serving a program that literally intended to install software on systems. You now have a large surface area random from typo attacks, to dns poisoning etc.

          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.