Package Repository Alternate Install for rustup

[naftulikay]

This thread is in response to this Twitter conversation.

It has been admitted for some time that providing a curl | sh installation solution leaves a lot to be desired as a way of installing rustc, cargo, and rustup.

While I’d ultimately like to see a Debian repository, an Ubuntu PPA, and a Copr for Fedora/RHEL for rustc and cargo, what I’m proposing is repositories along this line simply for rustup. Packaging rustc and cargo is a bit more involved that packaging rustup, so I believe that rustup would be a good start.

Since having the latest stable rustup is something desirable by everyone, the Rust community should officially provide repositories for it, and I am happy to contribute in this regard. Introducing a signed source-RPM build for Copr which would create packages for rustup for Fedora, RHEL 6/7 would not take a lot of time and should be fairly easy to integrate into the current Rust build workflow. The same goes for Debian and Ubuntu packages. Since I do believe that Rust is signing releases using PGP, it should be trivial to extend this model to then produce packages for these most popular distributions.

A little is also good in this regard, so even building packages with fpm would be a large improvement over curl | sh for security purposes.

I am happy to help in this endeavor, and like I have said, I don’t think we need to get it perfect the first time, the rule should be that adding the repository and installing the package should lead to a working rustup which can be further used to install a version of Rust, etc.

[comex]

How is adding some random URL as a repository any more secure than piping some random URL to sh? Either way, you’re letting the server run arbitrary code on your computer. I guess dpkg’s built in GPG support can be an improvement if you’re careful about verifying signatures and checking that the key is the real one, etc., but rustup could alternately just publish a .asc for the tiny group of people for whom that applies.

[naftulikay]

The main differences which are important to me are:

1. Cryptographic signatures and a chain of trust.
2. A clear understanding of what is installed.
3. Updates for security and otherwise.

Cryptographic Signatures and a Chain of Trust

While using TLS/HTTPS for serving your arbitrary shell script achieves the cryptographic property of authentication usually in the cipher configuration, cryptographic signatures like those provided by GnuPG provide both authentication and non-repudiation. Since Rust uses Keybase, it’s easy to get access to Rust’s PGP key and validate certain proofs about it, ie that whoever controls the rust-lang.org DNS also controls the PGP key, etc.

Adding a simple PGP signature to the rustup installer shell script would be a move in the right direction, but it doesn’t address further concerns.

Installation and Package Ownership

On both Debian and RPM-based systems, it’s trivial to query what a package provides for a given system. I can easily ask the package manager intelligent questions like “which package owns this file?” and more. I can also view logs of when said package was installed, when it was upgraded, etc. All these come for free when a repository is made.

Updates: Security and Otherwise

If I’ve installed rustup via curl | sh and a significant or not-so-significant security problem is found in rustup, I’m on my own. It’s up to me to follow forums, Rust’s twitter, an email list, or something else. Until I find out that there was a problem, I’m living with insecure software. Yes, Rust doesn’t suffer from a lot of security problems, but they still happen.

With a repository, a new package can be issued and pushed out and users will receive the newer version of the package. Some package managers allow tagging certain releases as security-related fixes and these can be automatically upgraded as security issues are found.

---

All of this is truly beyond the point, though. @comex it seems like you’re advocating for a world before package management was invented. The reasons listed above and so many other ones apply here. Package managers exist for a reason, and Rust would do well to at the least package rustup for the common distributions.

It’s not at all unreasonable to want to see PGP signatures, establish trust in what we are installing, and get updates in a timely fashion. Our distributions do that for us, and I am happy to volunteer my time to help get rustup packaged in Debian packages for latest Debian, Ubuntu LTS and recent releases, RHEL 6/7, and recent Fedora versions.

We lose nothing by doing this except the time which I’m willing to volunteer, and we gain a lot by this.

[jethrogb]

It shouldn't be too hard to turn binary releases of rustup into deb/rpm files. I think that is a much more convenient route right now than to write source packages, since it will be hard for anyone to meet the build dependencies (at least Rust 1.12 I think) through their package manager.

According to the source, installation is just:

Installing is a simple matter of coping the running binary to CARGO_HOME/bin, hardlinking the various Rust tools to it, and and adding CARGO_HOME/bin to PATH.

I wouldn't be surprised if things would "just work" if you put the binaries in /usr/bin.

Also found this related issue: Consider packaging rustup · Issue #800 · rust-lang/rustup · GitHub

[naftulikay]

This would be totally acceptable to me as a first pass.

[josh]

We’re working on packaging rustup and other tools written in Rust for Debian, using debcargo. It’ll take some time to get everything packaged, and rustup itself doesn’t yet have all its dependencies available on crates.io (see https://github.com/rust-lang-nursery/rustup.rs/issues/835), but the short list of Rust applications we want to package definitely includes rustup.

[comex]

I have nothing against package managers. The problem for me is that rustup essentially is a package manager. It downloads and executes binaries itself with its own trust system - which, incidentally, currently fails to verify PGP signatures, so for now you are no more secure from that angle. If you install rustup with a package manager, security fixes for rustup itself will be bundled into system updates, but security fixes for Cargo, the standard library, the compiler, etc. will not. And even then you will need to disable rustup self update, lest rustup fight with your package manager over its own binary.

I guess you did say that your ultimate goal was to package rustc and Cargo too, which would address those concerns (…well, most of them - still doesn’t deal with security bugs in Cargo packages), so I shouldn’t be too critical; I just don’t see much point in packaging rustup by itself.

[naftulikay]

Baby steps , one thing at a time.

Ruby’s gem and Python’s pip are both packaged by all major distros and at least pip has the ability to upgrade itself, so you’re on your own if you want to upgrade it.