cargo-crev

What it is #

cargo-crev (often called crev) is a code review system where every review is cryptographically signed by its author. It predates cargo-vet, and the underlying crev protocol is language-agnostic; cargo-crev is the Rust frontend.

Reviews are expressed in YAML and signed by a CrevID. A package review proof anchors to a (source, name, version) triple plus a recursive content digest of the reviewed source tree, and carries structured fields for thoroughness (none/low/medium/high), understanding (none/low/medium/ high), and rating (negative/neutral/positive/strong), plus optional advisories (known vulnerabilities), issues, flags, and a comment. A trust proof asserts a trust level (distrust/none/low/medium/high) in another CrevID with an optional comment.

A CrevID is an Ed25519 keypair, typically encrypted with a user-supplied passphrase. Proofs are stored as YAML blocks in plain text files within a per-user git repository, which the author maintains and others fetch from.

Workflow #

Auditor side: after forking a crev-proofs template repository, cargo crev id new --url <repo-url> creates a CrevID and clones the repository locally. cargo crev crate review <name> opens an editor pre-populated with a proof template; signing and committing writes the proof, and cargo crev publish pushes it upstream.

Consumer side: cargo crev verify reports each dependency’s review status against the configured trust graph. cargo crev repo fetch trusted pulls updates from already-trusted proof repositories; cargo crev repo fetch all additionally bootstraps from a hardcoded entrypoint (github.com/dpc/crev-proofs) and walks the trust graph outward.

Trust model #

crev’s trust model is a transitive web of trust. Every user signs trust proofs for other users at one of five levels (distrust, none, low, medium, high). At verification time, the trust graph is traversed from the consumer’s root identity outward, with configurable depth, level cost, and redundancy parameters; a reviewer’s effective trust is the result of that traversal.

Comparison to OpenVet #

cargo-crev was one of the tools that inspired OpenVet, so some of the design decisions that OpenVet made can be credited to cargo-crev’s prior work: per-actor signing keys, content-anchored audit subjects, a language-agnostic protocol, and structured review metadata richer than a single trust flag. However, OpenVet differs from cargo-crev in a number of ways, most prominently in the trust model.

The structural differences:

Trust model. crev’s trust is transitive: a reviewer’s effective trust is the result of graph traversal from the consumer’s root identity, with configurable depth, level cost, and redundancy parameters. OpenVet’s trust set is exactly the list of log URLs in the consumer’s openvet.toml, with no implicit graph behind it. The two systems therefore answer “how does a consumer benefit from audits written by people he/she has not directly listed?” differently: crev extends trust transitively through the graph, while in OpenVet a curator (an organisation, or an individual who aggregates) republishes audits from other auditors onto a log the consumer does trust. Each audit carries two signatures: the auditor’s, on the audit content, and the publisher’s, on the log commit. Attribution remains with the original auditor, and the publisher is explicitly accountable for what his/her log contains.

History integrity. crev proofs live in user-owned git repositories with no protocol-level append-only guarantee; a consumer detects a rollback only if he/she cached prior state. OpenVet logs are append-only signed commit chains, enforced by the protocol.

Distribution. A consumer using crev fetches each trusted proof repository in full via git, then looks reviews up locally. OpenVet uses content-addressed Merkle Search Trees indexed by audit subject, so a consumer fetches only the audits matching packages in his/her lockfile.

Discoverability. crev’s discovery model is repository-level: a consumer’s view of the network is bootstrapped from a hardcoded entrypoint (github.com/dpc/crev-proofs) and extended by walking the trust graph; to ask “who has audited package X?”, a consumer fetches all reachable repositories and searches locally. OpenVet’s public registry indexes audits by subject across the logs it hosts, so a consumer can search for audits of a specific package directly.

Ecosystem. The crev protocol is language-agnostic, but cargo-crev is the main maintained frontend and active reviews are concentrated on Rust crates. OpenVet ships a single CLI covering Cargo, npm, PyPI, Go modules, and RubyGems.

Authoring surface. Publishing a crev proof requires installing the tool, generating a CrevID with a passphrase, forking a proof-repo, editing YAML in an editor, and git push. OpenVet offers CLI and TUI authoring as well as a web authoring path on the registry. The web path uses GitHub sign-in, and the registry handles key generation and publishing (with opt-out for self-custodial key handling), so an auditor does not need to set up his/her own audit hosting to participate.

Organisations. A CrevID is one keypair; crev has no first-class notion of an organisation aggregating member reviews. OpenVet supports per-organisation logs with member-authored audits curated by the organisation.

Using alongside OpenVet #

OpenVet is intended as a replacement for cargo-crev, not a complement. Existing crev proofs are already signed by their authors, but the signature scheme and proof format differ from OpenVet’s, so migration involves re-signing rather than carrying the original signature across. The underlying review content (subject digest, structured fields, comment, advisories) maps over.