Hacker News Reader

Comment by dheera | Hacker News Reader

> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Oof. Can we please, please, please stop releasing software with "| sh"?

I love Rust but I have to agree installing rustup like that feels like a crime to my machine. For some time I would only install rustup when inside an air-tight virtual machine since I can't really bother to read the sh script every single time I'm going to download it.

It's 2023, we have package managers, we have packages, we have containers, why are we still shipping software like this? Even worse is the fact that you can generally find Rust in your package manager of choice but it will often be outdated and you won't be able to choose your versions the same you would with rustup.

I don't know, I'm not sure I have a solution, but I just wish maintainers would put a little more effort into trying to support package managers as the de-facto way to set up a tool chain such as Rust. Even if you want to keep the meta-package manager such as nvm or rustup, at least let me download _them_ from my distros repositories instead of running a random sh script from the internet.

How come do you trust the package of Rust from Rust but you don't trust the `sh` install script from Rust?

This specifically isn't an issue of trusting them with my system, it's that a shell script can give a shit all over a system without a good way to undo it, even if it was well-intentioned.

Package managers are modern technology, they exist because they can track what files were placed where, and can remove them cleanly when given an uninstall command.

Maybe the problem is the rust community seems to live on the bleeding edge and always needs to have a ‘nightly’ build to do anything interesting?

And distros usually don’t bump versions between releases because they just don’t. Run Debian Sid or Fedora Rawhide or <whatever> if that’s what you’re after.

> rust community seems to live on the bleeding edge and always needs to have a ‘nightly’ build to do anything interesting

You have an example of a project that needs nightly to build? I’m sure some exist, but nearly all libraries and projects live on the latest stable release.

That indeed used to be very common in the early days of Rust, however, I believe stable Rust is what most libraries and projects use nowadays. It's been some time since I saw anything that used Rust beyond 1.60 (release April last year) as a minimum version.

It's straightforward to set up an apt-get repository that updates nightly and have users use that. For something as widespread as Rust I expect better than curl | sh scripts.

Well I guess that solves the issue for one OS/distro.

It’s probably not _why_ they did it, but I certainly like that regardless of OS, installation is the same and it’s reliable.

It is a major part of why we did it. Giving everyone a nice flow for getting up and going matters for adoption.

That’s awesome.

For what it’s worth, I had a C# dev who’d never dealt with Rust at all before get themselves setup, and then compiling and running the Rust app by themselves in about 10 minutes flat (our internet is slow) and I definitely think the ease of the setup flow contributed to that hugely, so massive thanks for making it so nice.

Probably doesn’t matter for Rust but once you start messing with random system packages that other packages depend on it becomes less than straightforward really quick.

One simple version bump can effect hundreds of packages and, if you’re not careful, bork an entire install… ask me how I know that one.

—edit—

Also should say that I’m fully in the package manager camp. If I want to install something that’s not in the repos I almost always find or make a package and build it locally because I don’t want random orphaned files strewn around my system folders.

Unless it’s just some command line program then I usually just use it from the source directory and don’t even bother having it in my path.

Many Rust users are on platforms that apt does not support.

Why do you trust scripts from your package manager more than one from the official upstream Rust project? The Rust project also has a good security track record.

I trust them more because I choose who mantains the repos I use. I trust them more because I already have to trust them: they provide almost every single piece of software I run on my machine. In this case I'm on Fedora which has a good track record for security, stability, and only allowing free software.

It's not to say that I don't trust the Rust project, nowadays I kinda have to, but curl sh installation is messy and separated from the rest of the system. If they just packaged rustup into an rpm and set up their own repos I could point dnf to it would make system maintenance so much easier.

I just want them to use the tools that already exist instead of reinventing the wheel with an esoteric 700 lines-long sh script. This applies to Rust and any other kind of tooling that does the same installation workflow. I understand the reasoning behind it, but I believe the other options should also be considered and supported.

What's wrong with it as long as it comes from a https URL with low potential for typo squatting (a short .sh domain would be even more natural but maybe controversial and a bit expensive for just this)? You don't have to pipe it into sh, you can also redirect it ie "> install.sh" then examine it before running. What's the alternative? A dozen incompatible centralized lang-specific or distro-specific package managers? Might work for devs but not end users, might not work with all licenses, is extra work for distros + Mac OS so chances are the O/S you're using or would otherwise be using isn't covered, ...

Uninstallation issues.

I'd rather have package that tracks what files it installs and removes cleanly.

`rustup uninstall` will cleanly uninstall everything.

https://rust-lang.github.io/rustup/installation/other.html

The whole point of this installation method is ease of use. You can use it for convenience if you prefer it. I don't see the issue with providing more options not less.

Try examining the above script. It's a lot of work. It's not just a bunch of wget's and cp's, there are a bunch of subroutines and conditionals. Too much to look at.

Also as another user pointed out, uninstallation is a problem.

> Try examining the above script. It's a lot of work. It's not just a bunch of wget's and cp's, there are a bunch of subroutines and conditionals. Too much to look at.

This would be a reasonable counter-argument if most people could honestly claim to have inspected the source of >1% of the things they'd installed from apt-get/yum/etc.

"But I trust the maintainers of those repositories to verify correctness" - yes, and people trust the Rust maintainers, too.

I'll grant you that uninstallation is usually a good argument (though not in this particular case).

Sure, once we have a universal way to accomplish the task that's easier and safer.

Ansible provides a module to install OS packages. It works with apt, yum, dnf, pacman, etc. This is just one of the implementation wrappers around a universal way to accomplish the task. This same mechanism also allows uninstallations and relies on the OS to manage dependencies, which it does. This one true way necessitates the "OS package manager" being the way for an OS to manage packages. This exists, and tools exist to eliminate the need to memorize how to do these processes like update, remove, reinstall, rollback, etc. It also centralizes into one config Nd workflow your very limited number of trusted parties, what their GPG keys are, and how to validate, rescind, and securely handle and use those keys. It handles digest verification, sha sum validation, etc. One way to do this exists by as many names as there are distro families, but it's one way nevertheless. This way, with these keys, stored under the security postures built and refined over decades, exists. The people complaining that this one way should be used turn out to have a valid point, and your suggestion is important, so it sounds like you're in agreement: let's use the OS package manager when installing OS packages. This way should be foremost, recommended, and most prominent. It's easier and safer. Do you disagree?

Can we please, please, please have someone write the authoritative article on why this is _actually_ a bad idea, so that it can be linked next time this conversation comes up, rather than merely intimating that it's bad?

...Yes, I'm intentionally invoking Cunningham's Law in the hopes that it exists and someone will link it here. Just to do a little due diligence, I searched for some answers, and found:

* https://stackoverflow.com/a/29389868/1040915 - "Because you are giving root access to whatever script you are executing. It can do a wide variety of nasty things." - apt-get and yum require sudo too.

* https://stackoverflow.com/a/34016579/1040915 - "if the script were provided to you over HTTP instead HTTPS..." sure, no arguments there! So don't do that then! ... "if the connection closes mid-stream, there may be executed partial commands, which were not intended to" ok, an actually reasonable answer! (though see the next link)

* https://www.arp242.net/curl-to-sh.html - a pretty comprehensive article in support of `curl | sh`, which points out that it's of equivalent security to `git clone && cd dir && ./make`, and only very slightly less than using package managers (which provide checksums). It also points out you can avoid the "interrupted connection" issue by running within a function

* https://medium.com/@esotericmeans/the-truth-about-curl-and-i... - reiterates that interrupted connection issues are minor, and repeats some server-side exploits that could potentially happen (if you don't trust the server, don't _ever_ install anything from it, via any means!)

* https://news.ycombinator.com/item?id=11532599 - a discussion of an article (which, ironically enough, itself has an expired certificate) with, I'll admit, more comments than I was willing to read in-depth - but one comment https://news.ycombinator.com/item?id=11533515 points out that `curl | sh` is fully portable whereas package managers are not.

Don't get me wrong - given the choice, I'd rather have the audit log, built-in checksum, uninstallability, and other features of a package manager any day. I'm not arguing that `curl | sh` is _better_ than package managers. But I have always been a little baffled why it's portrayed as _so_ much worse (when installing from a trusted source, over HTTPS) as to be anathema and repugnant.

There’s nothing wrong with curl | sh other than people realising “damn, this software could be malicious!” Yes, it could be. Doesn’t mean a HTTPS link maintained by a project with a good security track record is actually serving malicious links though.

My biggest concern is typo-squatting.

> connection closes mid-stream

I get around this by using wget to download the script, and THEN use sh.

Releasing? No. But you're already free to consume it via some other means, such as your OS/distro's/choice of package manager. It's not really on tool authors to inform you how to use your (and every other choice of) package manager, nevermind ensure it's packaged for all of them.

Various distros have rustup packaged, so use that instead where available.

Reply on news.ycombinator.com