You're ultimately responsible for vetting your dependencies.

But in a world of NPM/PIP/Cargo/RubyGems - how do you do that? Can you keep up with ever-changing ecosystem?

crev is an actual code review system as opposed to typically practiced code-change review system.

crev is scalable, distributed and social. Users publish and circulate results of their reviews: potentially warning about problems, malicious code, or just encouraging high quality by peer review.

crev allows building a personal web of trust in people and code.

crev is a tool we desperately need yesterday. It protects against compromised dev accounts, intentional malicious code, typosquating, compromised package registries, or just plain poor quality.

We would like Crev to become a general, language and ecosystem agnostic system for establishing trust in Open Source code. We would like to have frontends integrated with all major Open Source package managers and ecosystems.

Consider joining crev gitter channel. Thank you!

Still early, but there's a team already, a lot of working code and ironed-out ideas.

The current focus is on a first concrete implementation of Crev: cargo-crev - a tool for reviewing Rust language crates published on crates.io. It is available in an alpha version.

See it in action:

Using crev you can generate cryptographically signed artifacts (Proofs). Proofs can share details of code reviews (whole releases, parts of the code), or specifying trust (or mistrust) into reviews of other people.

Example of Package Review Proofs that review a whole package (aka. library, crate, etc.):

-----BEGIN CREV PACKAGE REVIEW-----
version: -1
date: "2018-12-16T00:09:27.905713993-08:00"
from:
  id-type: crev
  id: 8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
  url: "https://github.com/dpc/crev-proofs"
package:
  source: "https://crates.io"
  name: default
  version: 0.1.2
  digest: RtL75KvBdj_Zk42wp2vzNChkT1RDUdLxbWovRvEm1yA
review:
  thoroughness: high
  understanding: high
  rating: positive
comment: "I'm the author, and this crate is trivial"
-----BEGIN CREV PACKAGE REVIEW SIGNATURE-----
QpigffpvOnK7KNdDzQSNRt8bkOFYP_LOLE-vOZ2lu6Je5jvF3t4VZddZDDnPhxaY9zEQurozqTiYAHX8nXz5CQ
-----END CREV PACKAGE REVIEW-----

When useful, it is possible to review particular files (Code Review Proof).

While your own reviews are very valuable, crev allows reviewing identities of other people to establish trust.

Proofs are stored and published in personal repositories for other people to use.

They can be also included in a relevant source code itself through submitting a PR to the original project.

crev collects Proofs from different sources, and builds a personalized web of trust. This allows answering queries like:

• Which of my dependencies don't have a sufficient (arbitrary) level of code review/trust?
• What were the changes in a project X, since I last reviewed it?
• and more!

• Not many people can review all their dependencies, but if every user at least skimmed through a couple of them, and shared that information with others, we would be in much better situation.
• Trust is fundamentally about people and community, not automatic-scans, arbitrary metrics, process or bureaucracy. People have to judge both: code (code coverage, testing, quality, etc.) and trustworthiness of other people (whos reviews do you trust, and how much).
• Code review tool should be language and ecosystem agnostic. Code is code, and should be reviewed.
• Trust should be spread between many people, so one compromised or malicious actor can't abuse the system.
• Code Review should be stored along the source code itself. Just like tests, documentation, or even design decisions.
• Web of Trust is personal and subjective: islands of Trust emerge spontaneously and overlap.

• Crev FAQ
• "cargo-trust: Concept"