That basically matches with what I expect, but I'm not sure that distros will even bother to package rustup in the base packages (as something that provides an alternative to a packaged item, not just a supplement, such as cargo). In this respect, the wants and needs of distros are often at odds with those of developers. Developers want the latest with all the features in front of their users, distros want something easy to maintain and support (which often means not changing, or on a predictable schedule). This is particularly hard on interpreted languages, as the version shipped matters a lot more for what will run, not just what will compile in your dev environment. There's a (relatively) long history here.

If rustup isn't part of the base (distro-provided) packages, it will definitely be part of some popular add-on repos though.

Yeah, I am aware :)

I was super annoyed when I found out Ubuntu ships an ancient node and nvm doesn't exist in the distro. I would love for rustup to exist in the distro, but we should (and probably are doing so) plan for cases without it.

In some cases, all you have to do is the minimal amount to make it easier on the distro users, and people will jump on it. That may be providing repos for debian and red hat based systems where you provide a rustup RPM. That takes care of both making it easy (if not quite as easy as piping a remote source to a shell), and more secure. The keys are cached when the repo is added or first accessed, so if bad rustup packages are uploaded at some later time, the package managers will complain, loudly, at least for people who already had it, which is better than nothing.

I think Rust is interested in doing more than the minimal amount, and has been discussing with maintainers already, but I'm not aware of the details. They probably can be found on threads on internals.rust-lang.org or users.rust-lang.org though.

rustup.rs already does check against Rust release signing keys, so that part is at least trivial to integrate.

> rustup.rs already does check against Rust release signing keys, so that part is at least trivial to integrate.

I saw that (which is good!), but that's actually a step removed from what I was referring to. If a repo provides rustup, the rustup package itself is verified, which is useful way to get rustup itself compared to the fairly prominent and obvious suggestion at Rust's download page[1], which is "$ curl -sSf https://static.rust-lang.org/rustup.sh | sh". Targeting rustup.sh itself would actually be a fairly effective attack, since it's the tool that does the download, that verifies the binary, and that is often (I assume) run in a transient manner, since it's suggested you pipe the web response directly to an interpreter. If it was attached successfully, we would all be lucky if all they did was do nefarious stuff directly from rustup.sh, and not try to install their own,slightly changed, builds of the compiler[2].

1: https://www.rust-lang.org/downloads.html

2: http://www.ouah.org/acmken.htm is a classic, and kind of a worst case scenario.

Oh, yes, this has been brought up before. I did mention it to brson, not sure if anything is planned. Should be. Rustup is still WIP, sort of :)