Hacker News Reader

Comment by Etheryte | Hacker News Reader

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.

View on HN

They do offer other installation methods already.

Installation via package managers (Debian/Ubuntu), using repo provided by ferron

https://ferron.sh/docs/installation/debian

Installation as a Docker container

https://ferron.sh/docs/installation/docker

And more.

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.

> using repo provided by ferron

This poses a similar security risk to executing the "curl-sudo-bash".

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

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.

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

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?

There's no guarantee that any install method is easily uninstallable, updateable, or cleanable either.

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

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

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?

I don’t trust them enough to run as root.

But you have to. Nginx, caddy, traefik, etc cannot run without root or even if you can, it would be way more limiting

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

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.

1) That isn’t true.

2) Even if it were, I’m not going to do so while evaluating an unknown program.

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.

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.

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

Read how Tls works. Many people Can mitm. That’s why we sign applications

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.

No because the apps are signed and have it's own chain of trust independent of tls

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.

What happens when your certificate authority goes after you

Reply on news.ycombinator.com