In reply to @chrysn:matrix.org
From a technical PoV, it'd be quite sensible for the lib.rs maintainer to stop hardcoding his opinions in lib.rs, and instead state their opinion in crev reviews, and make them trigger a "deprecated" / "unmaintained" / "bad for the planet" label on crates.

In reply to @saky:matrix.org
Hi! As an update, on the in-toto side of things, we've been looking at human review attestations as a whole, currently exploring situations which don't fall under the purview of crev like internal code review on PRs etc. Here's the thread if you'd like to keep an eye on it: https://github.com/in-toto/attestation/issues/77. We're looking at including crev attestations for dependency reviews as a subset of human review attestations.

In reply to @saky:matrix.org
Hey! It's been a while and this issue didn't have any movement for a bit. However, I've been putting together review schemas, one that maps to crev and another that maps to other code reviews in systems like gerrit, VCSs like Github and so on. Here's the PR: https://github.com/in-toto/attestation/pull/151

Aditya Sirish: I'm kind of lost on that PR. I don't have enough understanding of what in-toto is actually doing.

Happy to discuss anything if it's of any help.

Apologies, I got pulled into a thing.

In my mental model, I split up crev as follows, please correct me if I'm mistaken:
a) a well defined schema to capture dependency audit / review results.
b) a web of trust I can use to determine whether a dependency can be trusted even if I haven't reviewed it myself.

I also split in-toto into two parts.
a) a standardized ways to capture claims pertaining to software supply chain: code reviews, test results, build provenance, runtime trace, etc. Each of these use cases has well defined schemas for different tools to interoperate.
b) a policy engine that can consume these different types of claims (as attestations) and apply rules to.

The PR I've opened primarily focuses on bridging point a of both projects, and IMO the differences are relatively small right now. in-toto, for example, doesn't require documents to be JSON, though it does default to JSON. By interoperating, crev's web of trust mechanism is preserved, something that's not the case if in-toto tries to do its own thing entirely. An in-toto policy can choose to plug into crev's web of trust for deciding which reviews are trusted, it can also be disconnected where the use cases call for it. From the perspective of the producer, the same document can function in both contexts.

I agree that OSS devs are burdened so far and I'd hate to add another item on their agenda. One thing I was hoping for was for organizations to populate reviews through the OpenSSF or so but that didn't get any traction when I first discussed it. I'm now beginning to get involved in another WG at the OpenSSF that's focused on securing package repositories and I want to propose this again (the last time was in a different working group).

enough understanding of what in-toto is actually doing

In that PR, the main things being proposed are two schemas for code reviews. One for crev (human-review-crev.md) and one for VCS reviews (human-review-vcs.md). I've tried to maintain a 1:1 mapping with crev except one field name (timestamp) so that the differences can be abstracted to how the doc is serialized.

implementing own things, and using crev as a source of inspiration, than something to support.

To circle back, I'm a fan of crev and the web of trust for dependency code reviews. I'd personally prefer to support and be complementary to it rather than recreate parts of it without the whole. (I say personally because I'm a maintainer of parts of in-toto but also I'm the primary person working on code review attestations so...)

In my mental model, I split up crev as follows, please correct me if I'm mistaken

Right.

a policy engine that can consume these different types of claims (as attestations) and apply rules to.

Hmmm... How does it work? What's the plan here? So a bigger org would run something like that somewhere and maintain some "bussiness goals" that could include "all dependencies must have a positive crev review, rooted in some WoT" kind of thing?