cargo trust: Concept

Edit: This document is already a bit stale. Details still change. The project was renamed to cargo-crev and is actually in a workable state. Best way to get a good understanding of it, is to just give it a try.

---

So I started crev as an language and ecosystem agnostic tool for code review.

I played with it for a while, and explored the possibilities. I think I've now settled on some core mechanisms, and as I am working towards a cargo-trust - a self contained tool for reviewing and signing packages for Rust. It will depend on crev-lib and core-data libraries, but for the user it will be a self-contained tool.

Note: Not everything is exactly like this already in the code, so don't use it as instruction yet. It's only an explanation/design.

How it works

New users generate an ID:

$ cargo trust id new

The ID is key-pair, used to sign package reviews.

This command will also ask for git repository address. Git repository is used to publish reviews.

Now the user goes to their project and verify their dependencies:

$ cargo trust verify
Updating registry `https://github.com/rust-lang/crates.io-index`
/home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/toml-0.4.6 not trusted
/home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/unicode-width-0.1.5 not trusted
(...)
/home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.4.3 not trusted
/home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/syn-0.14.4 not trusted
/home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-x86_64-pc-windows-gnu-0.4.0 not trusted

Oops. It looks like we can't trust anything, yet.

Now there are two ways: one is to review crates by ourselves. Let's try this.

User picks one dependency, goes to that directory (eg. /home/dpc/.cargo/registry/src/github.com-1ecc6299db9ec823/unicode-width-0.1.5) and just thoroughly reviews the code.

After that we mark this package as trusted (in users opinion at least):

$ cargo trust project toml 0.4.6
Updating registry `https://github.com/rust-lang/crates.io-index`
Enter passphrase to unlock:

A password protecting our private key is required. Then user is able to edit the details of project review in a way similar to commit message in git commit. Comment can be added, and some details altered.

The whole thing creates and stores in the database something of this form:

-----BEGIN PROJECT REVIEW-----
date: "2018-11-28T12:03:10.502213920-08:00"
from:
  id: I4auyA-q5FlkkcqpmD9rp8Xe1pvsA_7hLWZgzDJVS44=
  url: "https://github.com/dpc/trust"
thoroughness: low
understanding: medium
trust: medium
digest: aa5418196844bbe2552f40120d1f9832e0b2ba89072e17ff8cacc8813819526f805da522f0c66d1c1c891a5dd15d5f067ddd310e9ac40ee6947086436088c315
-----BEGIN PROJECT REVIEW SIGNATURE-----
CvaxS-vqZNe5UdjrRlgRApuaDf9TAAX5sG4CioxMGEw96moxxoTmkRkFXWxoTDTnGuhsRUB4f6VPmZPM7S7DAA==
-----END PROJECT REVIEW-----

What happened here is that cargo trust calculated a recursive digest of the whole package, and signed it with the private key corresponding to I4auyA-q5FlkkcqpmD9rp8Xe1pvsA_7hLWZgzDJVS44=.

It's worth noting that user can also do cargo trust distrust <project> [<version>] to flag that there's something wrong with it, and it should not be trusted.

After that user can do:

$ cargo trust db git push

which will publish the review by doing git push to https://github.com/dpc/trust - url associated with my id.

If cargo trust verify is re-run, the status of toml will change to trusted now. cargo verify will look up proof database and see that the recursive digest of toml package content is reviewed, and cryptoghraphically signed by us. And we can trust ourselves!

User can keep reviewing packages, or can go online and look for other users and organizations that are using cargo trust (or crev - the name of the underlying library/project).

If the user finds some they think are trustworthy, they can:

$ cargo trust id kVgB_A8HT1jWzNS6Me0hdJS0Z62wxzS5Cpil4BbgEQQ=

In a way similar to cargo trust project, this will ask for private key password, allow user to add some comments and other fields, and produce the final artifact:

-----BEGIN CODE REVIEW TRUST-----
date: "2018-09-15T21:25:06.233910093-07:00"
from:
  id: I4auyA-q5FlkkcqpmD9rp8Xe1pvsA_7hLWZgzDJVS44=
  url: "https://github.com/dpc/trust"
trusted:
  - id: kVgB_A8HT1jWzNS6Me0hdJS0Z62wxzS5Cpil4BbgEQQ=
    url: "https://github.com/someuser/trust"
trust: medium
-----BEGIN CODE REVIEW TRUST SIGNATURE-----
PQiQ5mGJQEPULqRiSToIyIgrX2e0uRfjNPrJWA9ZuxKiMZG_quJp_sFXQCs37yFW7eeoYApK56cCCixNLS3_DQ==
-----END CODE REVIEW TRUST-----

a signed proof of trust.

After that user can do:

$ cargo trust db update

This will go and do a git pull from urls of all other users that we directly or indirectly trust, as thus "download updates": new reviews.

By a combination of doing own reviews, and finding other people worth trusting, eventually cargo trust verify will pass and all dependencies will become trusted.

There is much more details that I've omitted. Eg. there are different trust levels, and one is able to specify trust level requirements. Eg. "trust packages that are trusted by at least N other people (or me)".

But that's basically the idea for minimum lovable product: cargo trust, that could cover the whole Rust ecosystem with an impenetrable web of trust in a scalable way.