6 ms·

I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle

I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it doesn't truly help in terms of security or side-effects as it can still run scripts, so although ultimately the issue is still running binaries not vetted by your distro's maintainers)

staticassertion 5y ago
> I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
- f1refly 5y ago
  Actually it's not hard at all. All you need is a half-working build system and tar installed. You just create an additional build target and you're fine.
  - staticassertion 5y ago
    If you maintain the repository yourself now your setup instruction involves adding a custom apt repo, and then the installation. You also now have to handle multiple package managers, etc. A simple bootstrap script is pretty much as easy as it gets.
- bayindirh 5y ago
  > packaging and publishing debs is often going to be a lot more work Creating a baseline .deb file takes at most 10 minutes if you know what you're doing. To know what you're doing, you need to spend ~2 hours once. It's not rocket science (finding the documentation is tbh). :)
  - staticassertion 5y ago
    What about rpm? And then signing it? What's the benefit here?
    - bayindirh 5y ago
      When you set your CI/CD pipeline, creating packages, signing them and updating your repositories are all trivial tasks (been there, done that). In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise. If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
    - oddmiral 5y ago
      RPM is much simpler than deb: .spec is just single file with metadata, build recipe, and list of files. Example: https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5minute.spec https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5m... Signing of packages is used to protect from malware.
fiddlerwoaroof 5y ago
As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
- kevincox 5y ago
  White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
  - fiddlerwoaroof 5y ago
    If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
    - kevincox 5y ago
      Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS. I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
      - fiddlerwoaroof 5y ago
        We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy. Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.

staticassertion 5y ago

> I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.

f1refly 5y ago
Actually it's not hard at all. All you need is a half-working build system and tar installed. You just create an additional build target and you're fine.
- staticassertion 5y ago
  If you maintain the repository yourself now your setup instruction involves adding a custom apt repo, and then the installation. You also now have to handle multiple package managers, etc. A simple bootstrap script is pretty much as easy as it gets.
bayindirh 5y ago
> packaging and publishing debs is often going to be a lot more work Creating a baseline .deb file takes at most 10 minutes if you know what you're doing. To know what you're doing, you need to spend ~2 hours once. It's not rocket science (finding the documentation is tbh). :)
- staticassertion 5y ago
  What about rpm? And then signing it? What's the benefit here?
  - bayindirh 5y ago
    When you set your CI/CD pipeline, creating packages, signing them and updating your repositories are all trivial tasks (been there, done that). In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise. If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
  - oddmiral 5y ago
    RPM is much simpler than deb: .spec is just single file with metadata, build recipe, and list of files. Example: https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5minute.spec https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5m... Signing of packages is used to protect from malware.

fiddlerwoaroof 5y ago

As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.

kevincox 5y ago
White side effects does Nix have when you install a package? IIUC it just updates the programs that are symlinked into various locations (like a directory in your $PATH).
- fiddlerwoaroof 5y ago
  If you’re installing from a binary cache, that’s true, but a nix expression is just a build specification: it can run any program available to build and install a package. The “normal” way this works is you install the software to $out and $out gets copied into the nix store, but a malicious nix package can bypass this (and, assuming you’re not using nix’s sandboxing mechanisms, do arbitrary things to your computer).
  - kevincox 5y ago
    Building without a sandbox is really pushing the definition of "just installing a package". Also the sandbox is enabled by default on at lest NixOS. I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
    - fiddlerwoaroof 5y ago
      We aren’t really talking about installing packages from official distributions, right? We’re talking about things like installing an interesting tool from GitHub using the ability of nix to download an build master.tar.gz. In most of these cases, there’s always going to be some amount of reliance on the assumption that the developer of the software is trustworthy. Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.