-
Notifications
You must be signed in to change notification settings - Fork 91
Join crev gitter channel and let's talk! Or feel free to start hacking!
The design is open for adding support for PGP, Salty, Keybase and whatever else as identity systems.
Currently it is easiest for both the end user and the initial implementations to use its own public key based IDs, signing and WoT.
Please note that crev is just an additional line of defense, and does not
replace any others methods of securely handling your code and its dependencies.
It is part of crev's philosophy to rely on redundancy, instead of
trying to make everything "unbreakable". A compromised ID will just invalidate
itself and/or gets marked as untrustworthy by other users.
Also worth noting: systems like PGP don't carry enough information. Just because you verified that someone's PGP really belong to them, doesn't mean you trust their code review judgment. But the identity/signing system could be reused.
A Continuous Integration system will need to know where to fetch your reviews from, and which Id to trust. That information is provided in two steps:
cargo crev repo fetch url <URL>
cargo crev repo fetch trusted --for-id <ID>
where <URL> is the git URL for your repository, and <ID> is your root trust identity; this can be your organization root identity or your personal one.
If your CI system supports caching, adding ~/.cache/crev will speed up the fetching process.
Verification is then run as
cargo crev crate verify --all-features --for-id <ID>
which will give an unsuccessful return value unless all crates that are depended on have received sufficient review. You may want to adjust cost, redundancy and thoroughness requirements according to your expectations.
Yes, and you are encouraged to, with the same care as you review other crates. Someone who trusts you to review will trust you to rate your own crates as well.
Some additionally material on the topic can be found in issue #27.