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.

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.

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?

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.

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.

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:

1. 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.

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

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.

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.

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?

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.

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:

Bumps derive_builder from 0.11.2 to 0.12.0.

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.

Bumps blake2 from 0.9.2 to 0.10.6.

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.

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.

Bumps rprompt from 1.0.5 to 2.0.2.

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.

Bumps base64 from 0.13.1 to 0.20.0.

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.

The protection cargo-crev provides is flawed if cargo-crev itself can't be securely installed. Distro packaging is a very convenient and secure way to do that. However it needs a reasonable MSRV.

The current MSRV seems to be 1.62.0 which is just above 1.61.0 being in Debian Bookworm (will be stable in a few months). Because I'm currently unable to get bookworm running I tried "packaging" 0.23.0 and there seem to be quite a few missing dependencies so it won't be an easy task.