Crev Spec

[damien]

Hey folks!

I'm a huge fan of crev and work as a security engineer for my employer, Human Interest. We're considering spending some development time from our security engineering team to build out a working implementation of Crev for NodeJS and working with the broader NodeJS community to raise awareness and drive adoption of Crev.

We're aware of npm-crev, but that particular implementation seems to have stalled out. In looking at taking a stab at this on behalf of Human Interest, a few questions come to mind:

1. What, if any, formal specification(s) exists around Crev?
2. What, if any, existing governance structures exist around Crev and related tooling?
3. Would it be preferable for various implementations of Crev to use a common shared library to interface with code review artifacts, or is there a desire for language/ecosystem native and independent implementations of Crev? e.g. Would a mature Crev ecosystem center around a library, protocol, format, or some combination of the three?

Excited to hear from folks working on the project. Cheers!

[dpc]

some development time from our security engineering team to build out a working implementation of Crev for NodeJS

That would be sweeet!

What, if any, formal specification(s) exists around Crev.

At the very core crev is just an idea for an interoperable document format. As long as an implementation can read and produce these two types of simple documents like https://github.com/kornelski/crev-proofs/blob/1212a3226a5b2f7fe90fff2a995f1a77396bca72/rBGRONmiSLmELT1SuRDDScgLcoJl8mTdEbZqz1XCesM/reviews/2022-01-package-qnSWXg.proof.crev#L1 it's all good.

As you can see it's a simple yaml structure (so it's roughly human-readable), wrapped in this custom evelope with a signature. The crypto is fairly standard-common.

The type-definitions of the main implementation, are the closest thing to current spec.

cargo-crev/crev-data/src/proof/review/package.rs

Line 69 in eb4a5d2

pub struct Package {

cargo-crev/crev-data/src/proof/trust.rs

Line 94 in eb4a5d2

pub struct Trust {

cargo-crev/crev-data/src/proof/content.rs

Line 181 in 74563fd

fn sign_by(&self, id: &crate::id::UnlockedId) -> Result<Proof> {

cargo-crev/crev-data/src/proof/mod.rs

Line 196 in eb4a5d2

pub fn parse_from(reader: impl io::Read) -> Result<Vec<Self>> {

The data formats, etc. are already in possibly reusable libraries, so by adding some bindings could potentially be used directly from languages other than Rust. But writing native versions seems like a better idea to me (just encourages contributions within the given ecosystem, without additional language being a barrier).

Every else above that is kind of an implementation detail at this point. Git repos are used for distribution of updates, but they don't have to really. I would expect that eventually places like npm would support publishing/downloading proofs along with each package, etc.

Also - the standard is still at "version 0", which means there's a room for phasing in backward-incompat. changes. IMO, there isn't really much point in spending time on writting special specs. until multiple implementations are available, idea was confirmed and detailed hashed out.

[dpc]

What, if any, existing governance structures exist around Crev and related tooling

There isn't much if any. Just handful of contributors, and github repo and matrix channel to talk about stuff.

Would a mature Crev ecosystem center around a library, protocol, format, or some combination of the three?

IMO, the format of the documents is the interoperability surface: self-contained, self-explaining (to a point, at least), not too large to implement multiple times. Everything else depends on implementations and is still "in the air and flexible, subject to change".

[damien]

@dpc Thanks for the thoughtful responses!

What you've mentioned matches my current understanding of the state of Crev: there is one working reference implementation and not much formality past the existing document formats.

I think you're right in that a language native implementation would encourage adoption and contribution. I wonder though: would it be possible to model/sign/trust cross-ecosystem dependencies? For example:

1. A NPM package with bindings to a Rust package signed by cargo-crev.
2. A Cargo package that pulls NPM dependencies to bundle with a WASM build target.

I'm not sure how common these use-cases are, but from a corporate governance/risk perspective, having ways to perform attestations of things across larger segments of a tech stack would be invaluable.

I suspect I'm getting ahead of myself, but I think such use-cases could be fairly straightforward if some work is done to formalize what can reside in the YAML manifests generated by Crev-compatible tooling.

[dpc]

A NPM package with bindings to a Rust package signed by cargo-crev.

Fundamentally, yes. In practice I would imagine npm-crev would have to implement some fairly complex integration to make it possible. I'm not even sure if this sort of things (like how non-JS bindings are uniformly standardized, etc.) . Do they just use cargo directly? If so - npm-crev could example call cargo-crev to do core part or something like that.

Or possibly reviewing of NPM package that uses Rust code should just mean that the reviewer is responsible for vetting the Rust code, which would include using cargo-crev, and possibly preparing some extra-info to help automatically verify these as well.

Seems like a nice to have eventually, nothing worth worrying about at this point.

I'm not sure how common these use-cases are, but from a corporate governance/risk perspective, having ways to perform attestations of things across larger segments of a tech stack would be invaluable.

Agreed, though I always urge everyone to focus on what's achievable and practical right now to improve whatever can be improved soon, and not dwell too much on looking for perfect solutions. The problem is pretty much completely unaddressed right now, and I keep seeing in the security community this attitude of analysis paralysis and architecture astronautics, where cargo-crev seems like the only humble, minima,l yet actually working and striving to be practical project.

And the biggest problem with the whole idea are not actually the technical details, but some putting the effort and actually figuring out all the mundane details that would make the whole thing practical appealing to use: evangelizing, building documentation, user base, and so on.

The value of having a basic npm-crev actually being used out there, helping people cover the vast and fast paced area that NPM ecosystem in a more organized fashion would be tremendous improvement over the status quo. Everything else is secondary. And if you get enough traction, many people will sort out the more complex details eventually.

I think such use-cases could be fairly straightforward if some work is done to formalize what can reside in the YAML manifests generated by Crev-compatible tooling.

I forgot to mention, but the format is meant to be extendable. Tools that spot fields they don't understand, should just ignore them, and the meaning of the fields should be such that ignoring them should not change the meaning of more widely supported ones.

So while preserving the basic core fields and their meaning, npm-crev can just add anything it feels like it needs. At this point it's an almost clean canvas.

[damien]

Agreed, though I always urge everyone to focus on what's achievable and practical right now to improve whatever can be improved soon, and not dwell too much on looking for perfect solutions. The problem is pretty much completely unaddressed right now, and I keep seeing in the security community this attitude of analysis paralysis and architecture astronautics, where cargo-crev seems like the only humble, minima,l yet actually working and striving to be practical project.

Absolutely agree, I'm mainly brainstorming at this point. Sounds like we agree on the point of any functioning NPM Crev utility would be a tangible improvement in the state of security in that ecosystem.

I forgot to mention, but the format is meant to be extendable. Tools that spot fields they don't understand, should just ignore them, and the meaning of the fields should be such that ignoring them should not change the meaning of more widely supported ones.

Fantastic feedback, and exactly the kind of things I'd look to document as part of a spec or "how to" guide on building new Crev implementations. Speaking of which, if one wanted to contribute to documentation (both user facing and design) for Crev, what repo or project would such documents make sense? https://github.com/crev-dev/crev ?

Cheers!

[dpc]

Speaking of which, if one wanted to contribute to documentation (both user facing and design) for Crev, what repo or project would such documents make sense? https://github.com/crev-dev/crev

I guess. I am quite open here. I've parked the whole thing in crev-dev github organization, with a hope that eventually there would be more implementations and more people around it, but myself being focused on cargo-crev mostly. Whoever puts the effort to build things get to choose the details.

[damien]

@dpc Heard and understood! I'll ping this thread again when I have anything further to share. 🎉

Thanks for your time!