4 ms·

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irres

I know it's not popular to care about these things these days, but please consider a different installation mechanism than curl piped into sudo bash. It's irresponsible and normalizes a practice that never should've happened.

olalonde 1y ago
Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?
- adastra22 1y ago
  I don’t trust them enough to run as root.
  - udev4096 1y ago
    But you have to. Nginx, caddy, traefik, etc cannot run without root or even if you can, it would be way more limiting
    - QuantumNomad_ 1y ago
      Only for binding to ports under 1024 really, like 80 (http) and 443 (https). Once it has bound to the ports it can drop down to running as a low-privilege user (usually named www or httpd or similar). On Linux you can allow your program to bind to those ports even without running the program itself as root. https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443 https://superuser.com/questions/710253/allow-non-root-proces...
      - dorianniemiec 1y ago
        When installed for example with the installer script, Ferron would run on a specialized user for running the web server. Ferron itself would also have "CAP_NET_BIND_SERVICE" capability set on its binary, so that it doesn't have to run as root.
    - adastra22 1y ago
      1) That isn’t true. 2) Even if it were, I’m not going to do so while evaluating an unknown program.
  - deleted 1y ago
    [deleted]
- earthnail 1y ago
  Because untrustworthy websites can piggyback on the brand name. "Download ffmpeg here: sudo bash -c ..." And then the installation script from our malicious site installs ffmpeg just fine, plus some stuff you have no idea about. And you never know that you've just been hacked.
  - QuantumNomad_ 1y ago
    If you get your install instructions from an untrustworthy website, there’s nothing preventing them from telling you to use a third-party apt repository or ppa that gives you a malicious version of the thing. There’s not really a difference between curl piped to bash, and installing packages from a third-party package repository that the distro maintainers have no involvement in with.
  - dns_snek 1y ago
    Can you repeat this mental exercise for every other installation method you can think of? e.g. distributing deb/rpm files, distributing AppImages, asking users to add your custom repository and signing key? (Yes I know that the last one has built-in benefits for automatic updates but that's not going to protect you on initial installation and its benefits can be replicated in a more portable way in any other auto-update mechanism with a similar amount of effort) ((And if you have the patience to set up a custom repository, you can simplify initial installation process using a "curl|bash" script))
- deleted 1y ago
  [deleted]
- alexnewman 1y ago
  Read how Tls works. Many people Can mitm. That’s why we sign applications
  - dns_snek 1y ago
    If they can MITM the installation script delivered over HTTPS, they can also MITM the website delivered over HTTPS. You can have 10 step instructions for users to add your PGP signing key and install your APT repository, but what difference does it make? None at all. A malicious website will copy your instructions and replace the signing key and the repository URL with their own.
    - alexnewman 1y ago
      No because the apps are signed and have it's own chain of trust independent of tls
  - deleted 1y ago
    [deleted]
  - Sohcahtoa82 1y ago
    I've read how TLS works. No, you can't MITM it unless your server or client have been altered to be deliberately insecure (ie, having a server with a self-signed certificate or a client that doesn't verify certificates). If you could, the entire internet would be broken.
    - alexnewman 1y ago
      What happens when your certificate authority goes after you
deleted 1y ago
[deleted]
QuantumNomad_ 1y ago
They do offer other installation methods already. Installation via package managers (Debian/Ubuntu), using repo provided by ferron https://ferron.sh/docs/installation/debian https://ferron.sh/docs/installation/debian Installation as a Docker container https://ferron.sh/docs/installation/docker https://ferron.sh/docs/installation/docker And more.
- Etheryte 1y ago
  That's true, but that's not what's front and center. Curl-sudo-bash is the first thing you see on the site, all the other options are close to the bottom of the page. Defaults matter and people tend to use whatever is the first option presented to them unless they have a good reason to do otherwise.
  - olalonde 1y ago
    > using repo provided by ferron This poses a similar security risk to executing the "curl-sudo-bash".
    - QuantumNomad_ 1y ago
      Yeah I point that out too in a sibling comment. My personal opinion is that curl pipe to bash is not much worse than any other third-party binary installation method. (Third-party meaning from a source other than the package repo of your distro, or other than brew, or other than some kind of official App Store like thing on your platform.) If this project isn’t already available in the official package repos of various distros, it will eventually be. And for those more cautious among us you will probably want to wait until that point in time. For me personally I wouldn’t have any big concerns about the curl pipe bash install method on some of my servers. On my personal laptop (macOS), I’d probably rather build it from source (which is also a method available since it’s open source).
    - dorianniemiec 1y ago
      Yeah, it can be risky if Ferron servers get somehow compromised... The best bet would be using official distro repositories... But for now, I'm providing the .deb packages, so that people can easily install Ferron on Debian and alike.
maccard 1y ago
I care about these things. But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install
- yjftsjthsd-h 1y ago
  It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
  - maccard 1y ago
    There's no guarantee that any install method is easily uninstallable, updateable, or cleanable either.
    - spoiler 1y ago
      Yes, there's always sloppy packages, or ones that need side effects (but that's usually very rare, and sometimes even then it's because of sloppyness), but installing something via package manager comes with certain expectations (I can update it, I can uninstall it, it's usually got a few standardised places where its config lives, etc). curl|sh makes most of these things a greater nuisance rather than frictionless
    - yjftsjthsd-h 1y ago
      1. That's moving the goalposts; any normal package manager has significantly stronger likelihood of being able to do those things than curl|bash. Don't let perfect get in the way of good. 2. Actually, no, I will fight you on this: Unless you're actively trying to break them, docker, nix, flatpak, or any of their ilk will trivialize updates and give you guaranteed uninstallation and going full container will absolutely let you lock down exactly what an application is capable of touching or leaving behind (so, easy with podman/docker, varies with flatpak).

olalonde 1y ago

Can we stop with this nonsense already? If you trust them enough to run their server code, why wouldn't you trust them with the installation script?

adastra22 1y ago
I don’t trust them enough to run as root.
- udev4096 1y ago
  But you have to. Nginx, caddy, traefik, etc cannot run without root or even if you can, it would be way more limiting
  - QuantumNomad_ 1y ago
    Only for binding to ports under 1024 really, like 80 (http) and 443 (https). Once it has bound to the ports it can drop down to running as a low-privilege user (usually named www or httpd or similar). On Linux you can allow your program to bind to those ports even without running the program itself as root. https://superuser.com/questions/710253/allow-non-root-process-to-bind-to-port-80-and-443 https://superuser.com/questions/710253/allow-non-root-proces...
    - dorianniemiec 1y ago
      When installed for example with the installer script, Ferron would run on a specialized user for running the web server. Ferron itself would also have "CAP_NET_BIND_SERVICE" capability set on its binary, so that it doesn't have to run as root.
  - adastra22 1y ago
    1) That isn’t true. 2) Even if it were, I’m not going to do so while evaluating an unknown program.
- deleted 1y ago
  [deleted]
earthnail 1y ago
Because untrustworthy websites can piggyback on the brand name. "Download ffmpeg here: sudo bash -c ..." And then the installation script from our malicious site installs ffmpeg just fine, plus some stuff you have no idea about. And you never know that you've just been hacked.
- QuantumNomad_ 1y ago
  If you get your install instructions from an untrustworthy website, there’s nothing preventing them from telling you to use a third-party apt repository or ppa that gives you a malicious version of the thing. There’s not really a difference between curl piped to bash, and installing packages from a third-party package repository that the distro maintainers have no involvement in with.
- dns_snek 1y ago
  Can you repeat this mental exercise for every other installation method you can think of? e.g. distributing deb/rpm files, distributing AppImages, asking users to add your custom repository and signing key? (Yes I know that the last one has built-in benefits for automatic updates but that's not going to protect you on initial installation and its benefits can be replicated in a more portable way in any other auto-update mechanism with a similar amount of effort) ((And if you have the patience to set up a custom repository, you can simplify initial installation process using a "curl|bash" script))
deleted 1y ago
[deleted]
alexnewman 1y ago
Read how Tls works. Many people Can mitm. That’s why we sign applications
- dns_snek 1y ago
  If they can MITM the installation script delivered over HTTPS, they can also MITM the website delivered over HTTPS. You can have 10 step instructions for users to add your PGP signing key and install your APT repository, but what difference does it make? None at all. A malicious website will copy your instructions and replace the signing key and the repository URL with their own.
  - alexnewman 1y ago
    No because the apps are signed and have it's own chain of trust independent of tls
- deleted 1y ago
  [deleted]
- Sohcahtoa82 1y ago
  I've read how TLS works. No, you can't MITM it unless your server or client have been altered to be deliberately insecure (ie, having a server with a self-signed certificate or a client that doesn't verify certificates). If you could, the entire internet would be broken.
  - alexnewman 1y ago
    What happens when your certificate authority goes after you

deleted 1y ago

[deleted]

QuantumNomad_ 1y ago

They do offer other installation methods already. Installation via package managers (Debian/Ubuntu), using repo provided by ferron https://ferron.sh/docs/installation/debian https://ferron.sh/docs/installation/debian Installation as a Docker container https://ferron.sh/docs/installation/docker https://ferron.sh/docs/installation/docker And more.

Etheryte 1y ago
That's true, but that's not what's front and center. Curl-sudo-bash is the first thing you see on the site, all the other options are close to the bottom of the page. Defaults matter and people tend to use whatever is the first option presented to them unless they have a good reason to do otherwise.
- olalonde 1y ago
  > using repo provided by ferron This poses a similar security risk to executing the "curl-sudo-bash".
  - QuantumNomad_ 1y ago
    Yeah I point that out too in a sibling comment. My personal opinion is that curl pipe to bash is not much worse than any other third-party binary installation method. (Third-party meaning from a source other than the package repo of your distro, or other than brew, or other than some kind of official App Store like thing on your platform.) If this project isn’t already available in the official package repos of various distros, it will eventually be. And for those more cautious among us you will probably want to wait until that point in time. For me personally I wouldn’t have any big concerns about the curl pipe bash install method on some of my servers. On my personal laptop (macOS), I’d probably rather build it from source (which is also a method available since it’s open source).
  - dorianniemiec 1y ago
    Yeah, it can be risky if Ferron servers get somehow compromised... The best bet would be using official distro repositories... But for now, I'm providing the .deb packages, so that people can easily install Ferron on Debian and alike.

maccard 1y ago

I care about these things. But this is overblown. What’s your threat model here, you’re downloading a random thing from the internet and executing it. 99% of people are on single user machines, so root access doesn’t help, you’re screwed just by executing the thing if it’s malicious. Doing this is no worse than installing and running a random deb, or running npm install

yjftsjthsd-h 1y ago
It's not just a security thing. If you install something via curl|bash, how do you uninstall it? How do you update it? Do you know what it did to your machine? What config files it touched?
- maccard 1y ago
  There's no guarantee that any install method is easily uninstallable, updateable, or cleanable either.
  - spoiler 1y ago
    Yes, there's always sloppy packages, or ones that need side effects (but that's usually very rare, and sometimes even then it's because of sloppyness), but installing something via package manager comes with certain expectations (I can update it, I can uninstall it, it's usually got a few standardised places where its config lives, etc). curl|sh makes most of these things a greater nuisance rather than frictionless
  - yjftsjthsd-h 1y ago
    1. That's moving the goalposts; any normal package manager has significantly stronger likelihood of being able to do those things than curl|bash. Don't let perfect get in the way of good. 2. Actually, no, I will fight you on this: Unless you're actively trying to break them, docker, nix, flatpak, or any of their ilk will trivialize updates and give you guaranteed uninstallation and going full container will absolutely let you lock down exactly what an application is capable of touching or leaving behind (so, easy with podman/docker, varies with flatpak).