└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # Crev - Code REView system that we desperately need 2 | 3 | ## Implementations 4 | 5 | * [cargo-crev: Crev for Rust/cargo](https://github.com/crev-dev/cargo-crev) - ready and working 6 | * [npm-crev: Crev for Node/NPM](https://www.npmjs.com/package/crev) - baby steps 7 | * [pip-crev: Crev for Python/PIP](https://github.com/crev-dev/pip-crev) - still early 8 | * other languages/ecosystems 9 | 10 | ## Introduction 11 | 12 | You're ultimately responsible for vetting your dependencies. 13 | 14 | But in a world of NPM/PIP/Cargo/RubyGems - how do you do that? Can you keep up with ever-changing ecosystem? 15 | 16 | Crev is an actual *code review* system as opposed to typically practiced *code-change review* system. 17 | 18 | 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. 19 | 20 | Crev allows building a personal web of trust in other people and the code they use and review. 21 | 22 | Crev [is a][f] [tool][e] [we][d] [desperately][c] [need][b] [yesterday][a]. It protects against compromised dev accounts, intentional malicious code, typosquatting, compromised package registries, or just plain poor quality. 23 | 24 | [a]: https://www.csoonline.com/article/3214624/security/malicious-code-in-the-node-js-npm-registry-shakes-open-source-trust-model.html 25 | 26 | [b]: https://thenewstack.io/npm-attackers-sneak-a-backdoor-into-node-js-deployments-through-dependencies/ 27 | 28 | [c]: https://news.ycombinator.com/item?id=17513709 29 | 30 | [c]: https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/ 31 | 32 | [d]: https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/ 33 | 34 | [e]: https://www.itnews.com.au/news/rubygems-in-recovery-mode-after-site-hack-330819 35 | 36 | [f]: https://users.rust-lang.org/t/security-advisory-for-crates-io-2017-09-19/12960 37 | 38 | ## Vision 39 | 40 | We would like Crev to become a general language- and ecosystem-agnostic 41 | system for establishing trust in Open Source code. We would like to have 42 | frontends integrated with all the major Open Source package managers and ecosystems, 43 | and many independent and interoperable tools building on top of it. 44 | 45 | ## Overview 46 | 47 | At it's core Crev defines a simple, human-readable data format to communicate 48 | trust in code (results of code review) and people (reputation). 49 | 50 | Using tools implementing Crev, you can generate cryptographically signed artifacts (*Proofs*). 51 | 52 | Here is an example of a *Package Review Proof* that describes results of reviewing a whole package (library, crate, etc.): 53 | 54 | ``` 55 | -----BEGIN CREV PACKAGE REVIEW----- 56 | version: -1 57 | date: "2018-12-16T00:09:27.905713993-08:00" 58 | from: 59 | id-type: crev 60 | id: 8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE 61 | url: "https://github.com/dpc/crev-proofs" 62 | package: 63 | source: "https://crates.io" 64 | name: default 65 | version: 0.1.2 66 | digest: RtL75KvBdj_Zk42wp2vzNChkT1RDUdLxbWovRvEm1yA 67 | review: 68 | thoroughness: high 69 | understanding: high 70 | rating: positive 71 | comment: "I'm the author, and this crate is trivial" 72 | -----BEGIN CREV PACKAGE REVIEW SIGNATURE----- 73 | QpigffpvOnK7KNdDzQSNRt8bkOFYP_LOLE-vOZ2lu6Je5jvF3t4VZddZDDnPhxaY9zEQurozqTiYAHX8nXz5CQ 74 | -----END CREV PACKAGE REVIEW----- 75 | ``` 76 | 77 | *Proofs* are published and exchanged in a similar way that Open Source code is, for other people to benefit from. 78 | 79 | ## Fundamental beliefs of Crev design: 80 | 81 | * Trust is about people and community, not automatic scans, 82 | arbitrary metrics, process, or bureaucracy. You can't replace a human judgment 83 | with an algorithm. Tools can only help make such a judgment. 84 | * Code quality, risk management, and trust requirements are subjective, contextual, and personal. 85 | Islands of Trust must grow organically. 86 | * Not many people can review all their dependencies, but if every user 87 | at least skimmed through a couple of them, and shared that information with 88 | others, we would be in a much better situation. 89 | * Trust should be spread redundantly between many people, so one compromised or malicious 90 | actor can't abuse the system. 91 | * Crev does not have to be perfect. Instead it should be robust, simple and flexible, so 92 | it can evolve to be good enough. 93 | 94 | ## Further reading 95 | 96 | For more concrete information, see [cargo-crev - first and currently most advanced implementation of Crev](https://github.com/crev-dev/cargo-crev). 97 | --------------------------------------------------------------------------------