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.

      • Eager Eagle@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        3 days ago

        In most cases the script already installs a pre-compiled binary that can be anything, they wouldn’t need to make the script itself malicious if they were bad actors.

    • Admiral Patrick@dubvee.orgOP
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      2
      ·
      3 days ago

      I mean, how about:

      1. Download the release for your arch from the releases page.
      2. Extract to ~/.local/bin
      3. Run
        • Admiral Patrick@dubvee.orgOP
          link
          fedilink
          English
          arrow-up
          8
          arrow-down
          6
          ·
          edit-2
          3 days ago
          1. That’s been the 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 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.world
            link
            fedilink
            English
            arrow-up
            14
            arrow-down
            5
            ·
            3 days ago

            If you trust them enough to use their binary, why don’t you trust them enough to run their install scripts as well?

            • moonpiedumplings@programming.dev
              link
              fedilink
              English
              arrow-up
              5
              ·
              edit-2
              2 days ago

              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.

            • jatone@lemmy.dbzer0.com
              link
              fedilink
              English
              arrow-up
              6
              arrow-down
              1
              ·
              3 days ago

              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.

              • uranibaba@lemmy.world
                link
                fedilink
                English
                arrow-up
                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.com
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  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.world
                    link
                    fedilink
                    English
                    arrow-up
                    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.