Promotion of unsafe sysadmin practice

[kurahaupo]

The website gives heavy prominence to this one-line installation procedure:

wget -qO- https://omakub.org/install | bash

Following that instruction would be a disciplinary (possibly fireable) offence for a professional sysadmin.

• If the website name is mis-typed, and happens to hit a typo-squatter, that site could feed you any code, which could do anything to your system.
• Even if the site is genuine, it could be compromised, but there's no validation before the code starts to run: no check of a digital signature, or even something as basic as comparing hashes.
• Even if it's completely safe today, it trains users to ignore security.

Since Omakub targets web developers, that last point is unconscionable.

[matteeyah]

Even though I agree that this is an unsafe way to install anything over the internet, this practice is widespread. Many tools recommend installing them the same way - download a shell file and run it. The first that comes to mind is brew - https://brew.sh/.

There's no way, other than a package manager, to get the same level of convenience in a safe way. I ran into the same conundrum when I wanted to host my dotfiles. I ended up creating a symlink farm repository. The README itself is the SSOT of what needs to be done to use the symlink farm configs. For me, it was a fair trade off between convenience and being intentional about the commands that need to be ran. It's definitely not a drop-in replacement to a one-liner install, and requires more human effort, but not too much - up to 10 or 15mins.

Instead of replacing the whole approach, we could search for improvements that make this safer without sacricifing the convenience. Two ideas come to mind:

1. Adding checksum verification before running the install script
   • So we know the contents of it are genuine
2. Making the one-liner more explicit
   • So it's super clear what's going to happen
   • With a direct link to the shell script that's going to run.
   • It'd be clearer if we saw which file in the repository is going to run, instead of it being publicly hosted on the website. There's a redundant indirection in how Omakub executes - wget -qO- https://omakub.org/install | bash (https://github.com/basecamp/omakub-site/blob/master/install) essentially downloads another script and runs it eval "$(wget -qO- https://raw.githubusercontent.com/basecamp/omakub/stable/boot.sh)". This can be simplified by just having /bin/bash -c "$(wget -qO- https://raw.githubusercontent.com/basecamp/omakub/stable/boot.sh)" as the one-line install.

[ardentperf]

In another small project of mine, I switched to a 2-step approach (download with curl first, execute second)

ardentperf/dsef@8075584

I do think it's a little bit better to give someone the opportunity to inspect a script before they execute. Could also consider a checksum.

But really, if anyone cares enough to look at checksums they probably need to move to a formal distribution system anyway, which solves a lot more than just checksums. Anything being installed on servers probably should not be using curl from github in the first place, and software projects destined for servers will generally add multiple distribution channels as they mature. curl+github is usually for hackers and dev work; more formal distribution systems are for production use behind the corp firewall.

[kurahaupo]

Yes this practice is widespread; no that's not an excuse to keep recommending it, especially when the target audience includes many junior sysadmins.

Ideally the user should perform three steps:

1. download the script
2. inspect it
3. invoke it

Users who are not confident to inspect a shell script could instead be offered the option of visually confirming its checksum, preferably using something visual like the ssh host key fingerprinting method.

I agree that having two levels of curl | sh is silly; the /install URL should simply redirect to the boot.sh URL.

[dhh]

The trade-offs have been weighed here, and I'm comfortable with the choice.