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 point.

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. Thanks to this, Rust ecosystem does not feel fragmented. Jumping into a code authored by someone else does not feel like a venture into a foreign land, as it often does in other programming languages.

Together, this properties creates a language and 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 quality of building your software.

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 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 at least a couple of times 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. It's hard for me to say exactly what is his motivation, but it does not look good at all. It made me even more motivated to figure out a way to prevent incidents like this.

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, had some extremely serious performance problems, that made it pretty much unusable for serious purposes. The only way to discover this problem was finding one particular 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, or the version we're using is not known to have serious problems. Another accessible metric: judging by authors, becomes less and less practical, as the ecosystem and user base grows, more and more crates are published and crate ownership changes with time.

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

  • https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502
  • https://www.theregister.co.uk/2018/07/12/npm_eslint/

and 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 released cargo-crev 0.3.

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

cargo crev verify deps

The first column (status) show the cryptographically verifiable 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 of a given crate version and total number for all its versions,
  • 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. crev does not require everyone to spend hours carefully reviewing every line of code. A quick scan - looking for things clearly out of order - is still more valuable than no review at all.

While there's definitely more to talk about to fully introduce ideas behind cargo-crev and already implemented features, I hope this single screenshot, gives a good initial insight into its current state.

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 reuse" potential.

I know of at least 2 other Rust 2019 series posts voicing similar concerns:

  • https://medium.com/@GolDDranks/rust-2019-let-us-pursue-composability-70f1eb2238c3
  • https://vfoley.xyz/rust-2019/

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 Proof Repositories and feedback with us!

#programming #software