Code reuse in Rust

In my opinion, one of the biggest reasons why Rust is so productive is that it’s a superb language for code reuse.

First, ownership and borrowing system allows exposing in the API properties that are often impossible to express in other languages. The fact that the API communicates and enforces how the resources are being created, shared and moved and destroyed, all checked at the compilation time, gives the user great confidence that they are using any API — internal or external — correctly.

Second, Rust comes with first-class built-in tooling around discovering, creating, sharing and using publicly available Open Source libraries. It’s not a property unique to Rust, but it builds a powerful synergy when combined with the first one.

Third, the community (at least so far), were strongly encouraging uniformity and commonality: similar code style, similar documentation style, common core libraries, and patterns. A big chunk of this effort was achieved through great tooling like rustfmt and clippy.

Together, this creates a language/ecosystem where code reuse is almost effortless. While in other languages it’s often more tempting and more convenient to implement things yourself and avoid learning a new API, in Rust the difference between own and 3rd party code, often blurs completely. In a way, this creates a completely new

Despite all these strengths, there’s one problem that sticks out like a sore thumb: trust. Every additional dependency is another piece of code that we have could be buggy, or even malicious. And in my opinion, it’s problem so serious, that is entirely blocking the untapped potential of code reuse in Rust.

I’ve been personally bitten by this couple of times this in 2018.

One time, I’ve carelessly used a library that turned out straight buggy with the author refusing to fix or even admit the problem. I’ve used it because the name was very similar to a popular crate that I’ve used before. After I’ve investigated, turns out the author is crates.io name squatter and has plenty of almost-empty or poor quality libraries with very good names, and it’s hard for me to say exactly what is his motivation, but it doesn’t look good at all.

Another time, I’ve badly misjudged a library that looked good, had many authors, and yet, as I was pointed out by a fellow redditor, has some extremely serious performance problems, that makes it pretty much unusable until addressed. The only way to discover this problem was finding one github issue, between many other, innocent looking ones.

As things are right now, it’s very hard to judge the quality of a given crate. The only accessible metric available on crates.io is the download count. Not only can it be artificially inflated, but it is just unreliable: just because crate is popular, doesn’t mean it’s good. Another accessible way: judging crates by their authors, becomes less and less practical, as the ecosystem and user base grows.

On top of it, in 2018, there were at least a couple of instances where NPM ecosystem was shaken by serious security breaches:

It’s just a matter of time before issues like this will start happening in Rust ecosystem too.

About cargo crev

crev is a language and ecosystem agnostic Code REView system concept and cargo-crev is its first implementation — tightly integrated with Rust and crates.io.

The idea behind crev is fairly simple. You create a cryptographic ID, review packages in form of cryptographically verifiable proofs, publish your proofs online and share them with other users. Eventually, a Web of Trust is built, low-quality packages accumulate bad reviews, high-quality packages accumulate more and more good reviews, and it's easy to determine which packages are new and require a higher level of scrutiny.

Let’s take a tour over recently release cargo-crev 0.3

Here is the screenshot of using cargo-crev when reviewing its own dependencies:

The first column (status) show the cryptographically verifiable trust status of a given crate in a given version. In this case common_failures crate is verified because someone within my personal WoT (me), positively reviewed it.

The review proof is available in my Proof Repository

A crate negatively reviewed by someone in my WoT, would show a red flagged instead.

Following columns show:

  • reviews - the number of review proofs for a given crate version and all versions of it
  • downloads - https://crates.io download counters to help judge popularity
  • owners - a number of "known"/"total" crate owners; cargo crev edit known command allows editing a list of known and somewhat trusted crates.io users
  • crate and version - the dependency name and version used

The primary role of owners and downloads is to help narrow down the set of crates which are unpopular and/or don't come from known, well-respected authors. This is especially useful when starting using crev and trying to prioritize.

With time, I hope the number of users and circulating reviews is going to grow, shifting the focus from owners and downloads to status column.

A lot of crates are quite small, and low-intensity review of them takes around 10 minutes. It is not as titanic work, as one might think.

While there’s definitely more to talk about to fully introduce cargo-crev functionality and features, I think this single screenshot, should give a good initial insight into current state of cargo crev.

Now, after such a long introduction, here is the time for my Rust 2019 wish: I would like the Rust community in 2019 to solve the code trust problem and untap the “fearless code re-use” potential. I know of at least 2 other Rust 2019 series posts:

voicing similar concerns. So I now, I’m not the only one which would like this to happen.

I invite all Rust users to give cargo crev a try and share their reviews and feedback.