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.

  • Godort@lemm.ee
    link
    fedilink
    English
    arrow-up
    107
    arrow-down
    1
    ·
    3 days ago

    It’s bad practice to do it, but it makes it especially easy for end users who already trust both the source and the script.

    On the flip side, you can also just download the script from the site without piping it directly to bash if you want to review what it’s going to do before you run it.

    • thebestaquaman@lemmy.world
      link
      fedilink
      English
      arrow-up
      18
      ·
      3 days ago

      Would have been much better if they just pasted the (probably quite short) script into the readme so that I can just paste it into my terminal. I have no issue running commands I can have a quick look at.

      I would never blindly pipe a script to be executed on my machine though. That’s just next level “asking to get pwned”.

      • WolfLink@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        12
        ·
        2 days ago

        These scripts are usually longer than that and do some checking of which distro you are running before doing something distro-specific.

        • zalgotext@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          4
          ·
          2 days ago

          Doing something distro-specific in an install script for a single binary seems a bit overcomplicated to me, and definitely not something I want to blindly pipe into my shell.

          The bun install script in this post determines what platform you’re on, defines a bunch of logging convenience functions, downloads the latest bun release zip file from GitHub, extracts and manually places the binary in the right spot, then determines what shell you’re using and installs autocompletion scripts.

          Like, c’mon. That’s a shitload of unnecessary stuff to ask the user to blindly pipe into their shell, all of which could be avoided by putting a couple sentences into a readme. Bare minimum, that script should just be checked into their git repo and documented in their Readme/user docs, but they shouldn’t encourage anyone to pipe it into their shell.

    • Deello@lemm.ee
      link
      fedilink
      English
      arrow-up
      30
      arrow-down
      4
      ·
      3 days ago

      It’s bad practice to do it, but it makes it especially easy for end users who already trust both the source and the script.

      You’re not wrong but this is what lead to the xz “hack” not to long ago. When it comes to data, trust is a fickle mistress.