Replies: 4 comments 3 replies
-
Fundamentally, yes. In practice I would imagine 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 Seems like a nice to have eventually, nothing worth worrying about at this point.
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 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
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, |
Beta Was this translation helpful? Give feedback.
-
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.
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! |
Beta Was this translation helpful? Give feedback.
-
I guess. I am quite open here. I've parked the whole thing in |
Beta Was this translation helpful? Give feedback.
-
|
@dpc Heard and understood! I'll ping this thread again when I have anything further to share. 🎉 Thanks for your time! |
Beta Was this translation helpful? Give feedback.
-
|
@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:
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. |
Beta Was this translation helpful? Give feedback.
-
There isn't much if any. Just handful of contributors, and github repo and matrix channel to talk about stuff.
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". |
Beta Was this translation helpful? Give feedback.
-
That would be sweeet!
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/trust.rs Line 94 in eb4a5d2 cargo-crev/crev-data/src/proof/content.rs Line 181 in 74563fd cargo-crev/crev-data/src/proof/mod.rs Line 196 in eb4a5d2 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. |
Beta Was this translation helpful? Give feedback.
-
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:
Excited to hear from folks working on the project. Cheers!
Beta Was this translation helpful? Give feedback.
All reactions