I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method.

(pi.sh also documents other install methods, like `npm`, on their homepage)

If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass

    [1] https://news.ycombinator.com/item?id=9318286

▲ NekkoDroid an hour ago | parent | next [-]

I really hate the `curl <url> | sh` specifically because if your connection drops at a specifically unlucky point in time you are left with a partially executed script which if you are unlucky enough may just have been executing `rm -r ~/.cache/<pkg>/download` but it stopped at `rm-r ~/`.

Is it likely? No. Can it happen? Yea.

Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone.

▲ TacticalCoder 2 hours ago | parent | prev | next [-]

> I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world.

It's plain horrible. You could have, for example, a compromised server serving malware but only one out of every 100 download. The only signature you rely on is TLS.

Proper package distribution are using proper signatures schemes, are decentralized, even for some offer reproducible builds (meaning you can rebuild the whole package yourself and verify your build matches), etc.

Hashpipe is an attempt at reproducing some of those guarantees. Not unlike container pining using hashes. It at least fixes the "Jack and John installed this already and I know I'm getting the same version as they did".

Proper software distribution is signed, reproducible and ideally also uses some proof-of-existence for the hashes.

My bet is this: in the face of the countless supply chain attacks, we'll see more and more people getting very serious about security, including the security of software distribution. And curl bash'ing won't be part of it.

	▲	14 minutes ago \| parent [-]
		[deleted]

▲ tovej 3 hours ago | parent | prev [-]

What about better ideas like installing from source, or using a package manager? Or even flatpaks.

▲

arbll 3 hours ago | parent | next [-]

From source: creates much more work for the user.

Package managers: ecosystem is fragmented, requiring a long list of distro- and package-manager-specific instructions. Many scripts already install through package managers, they simply make the user’s life easier.

Flatpaks: These are clearly designed for desktop applications, with CLIs treated as an afterthought. They may be the best long-term hope, but today they are definitely not as convenient or widely available as a simple script.

If you care about adoption, `curl | sh` is the only real option today, which is why virtually all project show it as the first option.

▲

tovej 2 hours ago | parent [-]

Bullshit.

There's plenty of big projects that don't suggest you curl a script right into your shell.

If you have curl, you're probably on Linux. Just use the package manager like an adult.

	▲	arbll 22 minutes ago \| parent [-]
		The "like an adult" is what has and will continue to hold back linux on the desktop. Always gatekeeping less technical users instead of acknowledging adoption and ease of use are critical.

▲

mik3y 3 hours ago | parent | prev [-]

The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods.

Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example.

When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have.