FAQ

There are certain imperfections...

While I'm open for any ideas for improvements, I won't let the perfect kill the good enough. Any system of this kind would be a huge improvement over current situation.

Verification should be on crate/library/project level.

Having code-review on a file level is much more useful:

• Not all projects are small enough to review in one go. Some people might be competent/have enough time/personally be interested in a subset of eg. cryptographic library. It is still better to collect their per-file review, than not.
• Having file hash/revision allows answering querries like: which files have changed since I last reviewed, so I can re-review only them.
• Working on a file-level makes the interface much more natural (similiar to git).

I still plan to support release-integrity reviews, that recursively hash all files in subdirectories and collapse it to a single hash, that can be signed and used to check integrity post-release.

We should review packages, not repositories.

In crev you don't review "repositories". You review source code. The proof of your code review becomes part of the source code itself, just like documentation is usually a part of the source too. When the maintainers of the project release their library on crates.io/NPM/etc. the "tarball" contains the review proofs and the integrity of everything can still be verified.

If you were to review source code in central locations like NPM/crates.io you would lock users with these centralized services, and render the whole thing much harder to everybody else.

What about negative reviews

This must and will be supported for both code review and identity review. User will be able to express distrust, and thus warn other users.

To prevent malicious actors from silencing negative reviews, Code Review Proofs are independent of the source code itself. It will be possible to have otherwise code-less repositories containing only community maintained Code Review Proofs.

What about other identity systems (PGP, Salty, etc.)

It is easiest for both the end user, and initial implementation to implement it's own public key based IDs, signing and WoT.

Design is open for supporting PGP, Salty, Keybase, and whatever else in the future.

Note: Systems like that don't carry enough information. Just because you verified that someones PGP really belong to them, doesn't mean you trust their code review judgment. But the identity/singing system could be reused.

I would like to help

Join crev gitter channel and let's talk! Or feel free to start hacking!

I don't like the name

Well, I like it. It's a bit like "crew", it maps easily to "Code REView", it's short, and doesn't have a lot of hits on Google yet. I like discoverable names.

Please suggest alternatives, though!