A cryptographically verifiable code review system for the cargo (Rust) package manager.

crev - Code REView system

Last update: Jan 2, 2023

Related tags

Cryptography security review scalable code decentralized p2p code-review trust

Overview

cargo-crev

A cryptographically verifiable code review system for the cargo (Rust) package manager.

Introduction

Crev is a language and ecosystem agnostic, distributed code review system.

cargo-crev is an implementation of Crev as a command line tool integrated with cargo. This tool helps Rust users evaluate the quality and trustworthiness of their package dependencies.

Features

cargo-crev can already:

warn you about untrustworthy crates and security vulnerabilities,
display useful metrics about your dependencies,
help you identify dependency-bloat,
allow you to review most suspicious dependencies and publish your findings,
use reviews produced by other users,
increase trustworthiness of your own code,
build a web of trust of other reputable users to help verify the code you use,

and many other things with many more to come.

Getting started

Static binaries are available from the releases page.

Follow the cargo-crev - Getting Started Guide (more documentation available on docs.rs).

cargo-crev is a work in progress, but it should be usable at all times. Join our matrix or gitter channel, get help, report problems and feedback. Thank you!

Raise awareness

If you're supportive of the cause, we would appreciate helping to raise awareness of the project. Consider putting the below note in the README of your Rust projects:

It is recommended to always use [cargo-crev](https://github.com/crev-dev/cargo-crev)
to verify the trustworthiness of each of your dependencies, including this one.

Thank you!

Changelog

Changelog can be found here: https://github.com/crev-dev/cargo-crev/blob/master/cargo-crev/CHANGELOG.md

Comments

cargo_crev_web - web server to query reviews from cargo-crev

Hello, I like the cargo-crev system a lot. But it needs much more audience to spread. I think that the reviews of crates need to be on the web to allow anybody to see them. I prepared an idea. You can try it here: alternatives: https://bestia.dev/cargo_crev_web/query/btoi issues https://bestia.dev/cargo_crev_web/query/num-traits advisory https://bestia.dev/cargo_crev_web/query/protobuf The code is here: https://github.com/LucianoBestia/cargo_crev_web This is a prototype. I just copied the *.crev files from my cache to see how it works. I imagine the first question is: Every developer has a different list of trusted people. How to deal with it? I suppose that this reviews on the web are just informative. Better to have more reviews than less. Somebody with experience could suggest who to trust. This list could be modified any time. On the web server cargo-crev will update the cache/crev every day. The reviews are pulled from the repos of trusted persons - and their trusted persons.

I would like to hear what do you think about that? Thanks.

opened by bestia-dev 36
Own trust should override Web of Trust

There's a user who through my WoT got medium trust. I didn't trust them so much, so I made a trust proof with low trust. It didn't change the level of trust.

I assume WoT picks the maximum trust it can find, but I think my own Id should have the final say.

It worked for distrust level, but that seems overly negative. I'd like to be able to override WoT's trust with none and low too.

opened by kornelski 24
Is signing worth it?

I hope not to come off as overly critical, but this was something on my mind after tinkering about with crev locally. I think it would be valuable to reconsider the fact that the design uses signing, my reasons being:

From the security viewpoint, I can't personally see many scenarios the signing protects against. In practice it does not protect against GitHub going rogue (I think this is perfectly acceptable), as IDs to be trusted are fetched from a GitHub repository and then likely copy-pasted from the output into trust. That or they're copy-pasted from instructions hosted on GitHub.

A rogue/compromised user is caught out by testing crates directly from the package manager rather than the source. A rogue package manager is caught out by including a digest in the review.

Now for the main reason I opened this issue, I believe it would open up some benefits to adoption if there were no signing. Code review is a hard ask, and any barrier makes the ask harder still.

There would be no more need for key management. You don't have to worry about transferring it between devices in order to be able to review. You don't have to worry about losing it. You don't have to manage yet another password.

It would allow a simpler format and CLI. There would be no need for IDs, or to think of it another way the repo would be the ID. Trusting other users means just pointing at their repository. The file layout could be simplified to e.g. crev-proofs/reviews/*, the current format gives off an air of being opaque to human readers which may be off-putting.

It would be simpler to produce tools/integrations. Good integrations will be a massive benefit to the ecosystem: be it in the editor, GitHub bots to show if something lacks reviews on PRs, web UIs etc. Both the simpler format and lower complexity will increase the ease of creating any such tools.

It is of course a trade-off either way, the signing does provide trust on first use protection, my question would be is it worth the hit to usability?

opened by Alexendoo 24
Usability issues with the command-line interface
To me the "noun verb" grouping of commands is unhelpful. On a first glance it seems like a logical thing to do, but it has many problems in practice:

for many operations there's actually more than one thing involved, so it's unclear which noun is the special one. For example if an operation requires querying repositories about crate information it's entirely arbitrary whether that's crate info or repo query.

I can't develop intuition when to use cargo crev crate, because it changes the meaning of "crate" depending on subcommand. Sometimes it's the current crate, sometimes it's some other crate, sometimes it's search for crates. This seems wrong to me, because crate verify verifies my crate in the current directory, and given that I'd expect other crate subcommands to be consistent and also apply to my crate in the current directory, but they don't.

the choice of top-level nouns is odd. For example, reviews are an essential object for crev, but they weren't given a noun in the UI. There's no cargo crev review create. Instead of review delete there's crate unreview.

To me repositories are an implementation detail, more like a transport mechanism. So to me cargo crev repo is as weird as cargo crev http would be. Because most crev features are backed by some repo somewhere, the cargo crev repo subcommands perform lots of unrelated operations, from editing my readme to searching other people's reviews.

The commands are long to type. I've noticed you use an undocumented c v shortcut! Poor users who read cargo crev --help end up suffering the long versions.

There is no similarity between verbs. The verbs don't apply equally to the nouns. A "noun verb" design would make sense for a music player that allows song play and album play, but crev's nouns aren't interchangeable like that. In crev's case these are mostly just unique two-word commands.

structopt/clap doesn't think of them as nouns and verbs, but as nested subcommands. Because of that it doesn't display full commands, and cargo crev --help is useless.

Look at cargo itself. It has cargo update, not cargo index update. It has cargo build, not cargo crate build. cargo publish, not cargo package publish. Flattening of options allows cargo --help to display the most common and most useful options.
opened by kornelski 22
Add new "proof reissue" command
PoC implementation for this discussion: https://github.com/crev-dev/cargo-crev/discussions/492 "How to deal with a person leaving an organization?"

This commands allows to find existing proofs and sign them again with a different id.

This comes in handy when an id is going be revoked but the trust of the existing reviews should be retained by a new id.

Scenarios:

Old id got compromised

Person leaves an organization, so organization can reissue existing reviews using a different id to maintain trust level.

Checklist:

[x] cargo +nightly fmt --all

[ ] Modify CHANGELOG.md if applicable

Code is originally based upon the "proof find" code.
opened by thomasjfox 20
Can't commit or pull reviews: UnbornBranch
After cargo crev review foo I get:

Error: Could not not automatically commit caused by: reference 'refs/heads/master' not found; class=Reference (4); code=UnbornBranch (-9)

There are two problems here:

There is a not-completely-initialized repo somewhere. It may be my fault, as I've tried earlier version of cargo-crev and didn't fully follow instructions.

The error doesn't show path to the repo, so I don't know where it is, and I can't fix it.

bug enhancement maybe?
opened by kornelski 17
Want to help? Just try out `cargo crev` and give feedback.

cargo-crev is kind of working already. In a sense it's even quite feature complete (alpha quality though)

See https://github.com/dpc/crev/tree/master/cargo-crev for instructions.
help needed good first issue

opened by dpc 17
Unable to connect to repo using Gitlab Access Token

Does cargo-crev support the use of Gitlab Access tokens?

cargo crev id new --url username:token@url

When I do, I get the following error:

Couldn't clone https:username:token@url remote authentication required but no callback set; class=Http (34)

I can successfully clone the same repo using git and that format.

opened by desandy 16

Verification does not work as expected

I've got a project, that uses the log-0.4.6 crate.

I trust you and also fetched your reviews:

$ cargo crev query id trusted
8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
Kvz2HoEIOc4U9Gg3vNDbTVO54yF1YX6RuGi2o8pZkIs

$ cargo crev query review log
version: -1
date: "2018-12-16T14:37:00.691648406-08:00"
from:
  id-type: crev
  id: 8iUv_SPgsAQ4paabLfs1D9tIptMnuSRZ344_M-6m9RE
  url: "https://github.com/dpc/crev-proofs"
package:
  source: "https://crates.io"
  name: log
  version: 0.4.6
  digest: Y1F9HJSB_b1oFc1wz1qlblXXLoDyquDcVGM4g3SAhBk
review:
  thoroughness: low
  understanding: medium
  rating: positive

but when I want to verify my project's deps, the log crate has the status unknown

$ cargo crev verify deps | grep log-
    Updating crates.io index
unknown  /home/hirschen/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.6

What am I doing wrong?

bug

opened by hirschenberger 16

Setup remote Github repo if username available

Currently, users must setup a Github repository using the Github website before trying out crev. This PR should include changes which would allow a user to create a remote Github repo from crev directly using cargo crev new id.

The Github username can be given directly or extracted from a github repo URL.

This isn't perfect but should make it easier for people to try out crev.

opened by ffranr 16
Add new crev logo.

Last Sunday, I had a go at making a logo for crev. What do you guys think?

I don't do this professionally, and I have thick skin, so please feel free to give honest feedback. It was fun to make regardless of whether you guys want to use it or not.

I've tried to capture the idea of dependencies coupling together such as to form a protective shield.

I took the README centering setup from here: https://github.com/meilisearch/MeiliSearch

Light rendering on my computer:

Dark rendering on my computer:

opened by ffranr 15
Bump tokio from 1.23.0 to 1.24.1
Bumps tokio from 1.23.0 to 1.24.1.

Release notes

Sourced from tokio's releases.

Tokio v1.24.1

This release fixes a compilation failure on targets without AtomicU64 when using rustc older than 1.63. (#5356)

#5356: tokio-rs/tokio#5356

Tokio v1.24.0

The highlight of this release is the reduction of lock contention for all I/O operations (#5300). We have received reports of up to a 20% improvement in CPU utilization and increased throughput for real-world I/O heavy applications.

Fixed

rt: improve native AtomicU64 support detection (#5284)

Added

rt: add configuration option for max number of I/O events polled from the OS per tick (#5186)

rt: add an environment variable for configuring the default number of worker threads per runtime instance (#4250)

Changed

sync: reduce MPSC channel stack usage (#5294)

io: reduce lock contention in I/O operations (#5300)

fs: speed up read_dir() by chunking operations (#5309)

rt: use internal ThreadId implementation (#5329)

test: don't auto-advance time when a spawn_blocking task is running (#5115)

#5186: tokio-rs/tokio#5186 #5294: tokio-rs/tokio#5294 #5284: tokio-rs/tokio#5284 #4250: tokio-rs/tokio#4250 #5300: tokio-rs/tokio#5300 #5329: tokio-rs/tokio#5329 #5115: tokio-rs/tokio#5115 #5309: tokio-rs/tokio#5309

Tokio v1.23.1

This release forward ports changes from 1.18.4.

Fixed

net: fix Windows named pipe server builder to maintain option when toggling pipe mode (#5336).

#5336: tokio-rs/tokio#5336

Commits

31c7e82 chore: prepare Tokio v1.24.1 (#5357)

8d8db27 tokio: add load and compare_exchange_weak to loom StaticAtomicU64 (#5356)

dfe252d chore: prepare Tokio v1.24.0 release (#5353)

21b233f test: bump version of async-stream (#5347)

7299304 Merge branch 'tokio-1.23.x' into master

1a997ff chore: prepare Tokio v1.23.1 release

a8fe333 Merge branch 'tokio-1.20.x' into tokio-1.23.x

ba81945 chore: prepare Tokio 1.20.3 release

763bdc9 ci: run WASI tasks using latest Rust

9f98535 Merge remote-tracking branch 'origin/tokio-1.18.x' into fix-named-pipes-1.20

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the Security Alerts page.

dependencies rust
opened by dependabot[bot] 0
Bump derive_builder from 0.11.2 to 0.12.0
Bumps derive_builder from 0.11.2 to 0.12.0.

Release notes

Sourced from derive_builder's releases.

v0.12.0

Produce error when default is used with field(type = "...") rather than silently ignoring default #269

Add support for crate = "..." to support re-export scenarios #274

Commits

5705f00 Bump version to 0.12.0

378a3a3 Don't hide the Builder macro in docs

2439b97 Add compile tests for crate = "..."

757a8c5 Update unit tests to use ::db

e872faf Add #[builder(crate = "...")] at struct level

53fd62f Fix spelling: conusuming -> consuming

48a3033 Fix typo in custom setter documentation

e2a1a7b Produce error for default with field.type

5cf5f0a Split trybuild tests out to own job

45cf09a NFC: Remove unused lifetime

See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies rust
opened by dependabot[bot] 0
Bump blake2 from 0.9.2 to 0.10.6
Bumps blake2 from 0.9.2 to 0.10.6.

Commits

1f727ce blake2: release v0.10.6 (#443)

f8b2eab blake2: add Cargo feature to optimize for code size. (#440)

13dcab4 sha1: fix readme links (#439)

5da21fb Update Cargo.lock

8bf26e1 sha3: add asm feature (#437)

7556fe2 build(deps): bump keccak from 0.1.2 to 0.1.3 (#436)

fc543bc blake2: implement KeyInit::new in terms of KeyInit::new_from_slice (#435)

712f3df blake2: release v0.10.5 (#434)

881b21f Fix KeyInit for blake2 (#432)

af0567f Fix: typos (#428)

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies rust
opened by dependabot[bot] 0
Do not fetch anything after `cargo crev trust`

I have just spent a bunch of time investigating a spooky error of not being able to fetch unrelated URL, after I was signing a trust proof.

Fetching after creating new trust proof is a bit too much automation. It also delays the completion of the actual operation that was invoked.

opened by dpc 4
Bump rprompt from 1.0.5 to 2.0.2
Bumps rprompt from 1.0.5 to 2.0.2.

Release notes

Sourced from rprompt's releases.

v2.0.2

This release updates the API in line with recent changes in rpassword, to be more flexible.

Migration guide

Replace prompt_reply_stdout and prompt_reply_stderr with prompt_reply and in most cases you should be fine. The new function prints to the TTY, so if you rely on the output being on stdout/stderr, you'll have to use the prompt_reply_from_bufread version, passing std::io::stdin(), std::io::stdout() and/or std::io::stderr() as arguments.

⚠️ The read_reply() now reads from the TTY instead of stdin, so if you need the old behavior, use read_reply_from_bufread in combination with std::io::stdin(). This should be fine in most cases, but may break code using pipes.

API changes

Old API was:

fn prompt_reply_stdout(prompt: &str) -> std::io::Result<String> fn prompt_reply_stderr(prompt: &str) -> std::io::Result<String>
fn read_reply() -> std::io::Result<String>

New API is:

fn prompt_reply(prompt: impl ToString) -> std::io::Result<String> fn prompt_reply_from_bufread(reader: &mut impl BufRead, writer: &mut impl Write, prompt: impl ToString) -> std::io::Result<String>
fn read_reply() -> std::io::Result<String> fn read_reply_from_bufread(reader: &mut impl BufRead) -> std::io::Result<String>

Commits

45a72f9 Publish rprompt, rclio and rooster

8f7e807 Remove tests of individual crates

32f601f Rename rutil to rtoolbox for publishing to crates.io

ae4ea51 Add contributing guidelines

4e079a3 Simplify directory structure after switch to workspaces

d9716f3 Use Cargo workspaces instead of symlinks

b3b24c2 Handle Ctrl-U in rpassword

ef3972d Fix use of serde after removing it from rpassword

ca4e559 Remove serde dependencies from rpassword

707d79f Bump rpassword to 6.0.0

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies rust
opened by dependabot[bot] 0
Bump base64 from 0.13.1 to 0.20.0
Bumps base64 from 0.13.1 to 0.20.0.

Changelog

Sourced from base64's changelog.

0.20.0

Breaking changes

Update MSRV to 1.57.0

Decoding can now either ignore padding, require correct padding, or require no padding. The default is to require correct padding.

The NO_PAD config now requires that padding be absent when decoding.

0.20.0-alpha.1

Breaking changes

Extended the Config concept into the Engine abstraction, allowing the user to pick different encoding / decoding implementations.

What was formerly the only algorithm is now the FastPortable engine, so named because it's portable (works on any CPU) and relatively fast.

This opens the door to a portable constant-time implementation (#153, presumably ConstantTimePortable?) for security-sensitive applications that need side-channel resistance, and CPU-specific SIMD implementations for more speed.

Standard base64 per the RFC is available via DEFAULT_ENGINE. To use different alphabets or other settings (padding, etc), create your own engine instance.

CharacterSet is now Alphabet (per the RFC), and allows creating custom alphabets. The corresponding tables that were previously code-generated are now built dynamically.

Since there are already multiple breaking changes, various functions are renamed to be more consistent and discoverable.

MSRV is now 1.47.0 to allow various things to use const fn.

DecoderReader now owns its inner reader, and can expose it via into_inner(). For symmetry, EncoderWriter can do the same with its writer.

encoded_len is now public so you can size encode buffers precisely.

Commits

9fcde48 v0.20.0

68919ae Merge pull request #202 from marshallpierce/mp/edition-2021

f58f441 Also updated fuzzers

d86e8c8 Update to edition 2021

766fbc9 Merge pull request #198 from marshallpierce/mp/invalid-padding

250323c More fuzzer fixes

bcbc669 Minor cleanup

604a3ca fix fuzzers

0996b81 Merge branch 'master' into mp/invalid-padding

442a809 Merge pull request #197 from marshallpierce/mp/update-msrv

Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR

@dependabot recreate will recreate this PR, overwriting any edits that have been made to it

@dependabot merge will merge this PR after your CI passes on it

@dependabot squash and merge will squash and merge this PR after your CI passes on it

@dependabot cancel merge will cancel a previously requested merge and block automerging

@dependabot reopen will reopen this PR if it is closed

@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually

@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)

@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies rust
opened by dependabot[bot] 0