8 ms·
Crev: dependency vetting with a web of trust
- kuhhk 8y ago> crev is scalable, distributed and social. Users publish and circulate results of their reviews: potentially warning about problems, malicious code, or just encuraging high quality by peer review. I like this. It would be nice to flag questionable areas outside of the maintainer's control, for other experts to look at. Sometime's I've seen something fishy that I share with a friend/colleague who might know how to interpret it, but often times it's in a language/framework that I might not have a friend to ask. The open source saying "given enough eyeballs, all bugs are shallow" has always been a faux pas, because there has never been enough eyeballs, especially on small projects. However, something like this could begin to close the gap. +1 from me
- infogulch 8y ago"given enough eyeballs, all bugs are shallow" is a reasonable theory but it includes some dubious assumptions like the distribution of eyeballs over code being or uniform (or proportional to use), frictionless planes, and spherical cows. We may be stuck with spherical cows, but hopefully something like this can help smooth over the eyeball distribution assumption.
- awinter-py 8y agotrust networks for software supply chain, love it
- pornel 8y agoSome background on this: Cargo makes it very easy to add dependencies. Rust has the same culture of small, single-purpose libraries as npm (there is https://crates.io/crates/left_pad https://crates.io/crates/left_pad if you're wondering). This of course raises the question: what if someone puts some malware in a crate? Cargo itself has an OK security (and working on more end-to-end integrity checks), so it's unlikely that someone will inject malware into existing crates, but that still leaves question of trusting the original crate authors. Rust is not a sandbox language. Even the "safe" subset of the language is still just about preventing bugs, but nowhere near a watertight sandbox required to protect programmers and users from straight-up malware running in their own program. It's not clear if that is even possible in an efficient, low-level systems programming language. So the most reasonable way forward is to ensure that all code you use is either from people you trust, or has been verified by you or someone you trust. Turning code reviews into a shareable artifact is a pretty cool addition here, as it reduces duplication of work across the community (you don't have to review everything personally), and helps you pick and choose who you trust.
- nicoburns 8y agoI'm pretty sure the left-pad crate is a joke. That functionality is in the standard library...
- deleted 8y ago[deleted]
- tln 8y agoThe only dependency of left_pad: https://crates.io/crates/kik https://crates.io/crates/kik "waiting for a takedown notice :P"
- richardwhiuk 8y agoThat's not a dependent on left pad, that's something which depends on left pad.
- eridius 8y ago> Rust is not a sandbox language. Even the "safe" subset of the language is still just about preventing bugs, but nowhere near a watertight sandbox required to protect programmers and users from straight-up malware running in their own program. Not only that, but even just the act of building a dependency is unsafe as dependencies can specify build scripts (which is just Rust code that's compiled and executed prior to building the crate).
- stcredzero 8y agoCargo makes it very easy to add dependencies. Rust has the same culture of small, single-purpose libraries as npm This of course raises the question: what if someone puts some malware in a crate? Do decentralized web of trust schemes actually work? What are the precedents? AFAIK, only centralized webs of trust work, and even those still leak around the edges and take some degree of active policing to defend. Basically, someone (or maybe a few competing someones) with authority establishes a canonical boundary and publishes a canonical list.
- 8y ago
- 3pt14159 8y agoYES! Please let this or something like this take off! I've been saying for years that webs-of-trust are the solution for so many problems, including this one.
- mindB 8y agoThere's some more background and vision for this software in this blog post talking specifically about the Rust ecosystem: https://dpc.pw/cargo-crev-and-rust-2019-fearless-code-reuse https://dpc.pw/cargo-crev-and-rust-2019-fearless-code-reuse It also has some nicer narrative examples.
- alexchamberlain 8y agoIt would be really cool if this could express claims about copyright and license, as well as code quality.
- mindB 8y agoCould you elaborate on what you mean by this? Were you wanting people to be able to publish proofs that they've reviewed the legal standing of the code as well as the code itself for problems?
- fiddlerwoaroof 8y agoIt would be useful to know if the MIT library you’re depending on pulls in a AGPL transitive dependency.
- mindB 8y agoI don't see how a cryptographic WoT system is necessary for that kind of concern. That sounds like more tooling needed around the language's basic packaging system.
- alexchamberlain 8y agoYeah. For example, the original author could declare they own the copyright on xyz release and its released under a certain licence
- wyldfire 8y agoThat's stipulated by the crate metadata and the only authority of that claim is the author's, right? Why would you want/need bolstering of that claim by a web-of-trust? What would it mean if the WoT identified a different copyright owner than the author or a different license from the one the author offers?
- wyldfire 8y agoI don't think you want/need web-of-trust to evaluate licensing. You probably just want to see "what is the full set of (transitive) licenses I'm agreeing to when taking on this new dependency?" Right? If so, there's cargo-license [1] for that. [1] https://github.com/onur/cargo-license https://github.com/onur/cargo-license
- weinzierl 8y ago> Trust is fundamentally about people and community This is so important. We souldn't trust packages but the people that assume responsibility for them.
- tln 8y agoThis is a great effort. I hope this takes off and some organizations become vetting entities. It's a lot easier to trust eg Lyft Engineering vetting than Joe Xyz at a glance.
- z3t4 8y agoHow does Crev's web of trust work !? What if the malicious user creates a bunch of fake id's to sign the compromised code ?
- riffraff 8y agoWho would trust those?
- z3t4 8y agoThen the question becomes, how do you know who to trust ? Are you supposed to also vet the id-hashes of the signers ?
- sgeisler 8y agoI guess you will trust coworkers, people you know irl, well known developers, companies you pay for review subscriptions. You don't have to trust all of them 100%if you require multiple reviews per dependency.
- mikekchar 8y agoI have a similar thought. WoT relies upon authentication. How does Crev do authentication? What methods are used for key revocation, etc? It didn't seem to me that they were tackling that directly but relying on a proper use of underlying technology. Possibly I'm wrong or possibly they haven't got that far, but I'd love to see a more explicit description of exactly what they've thought out so far.
- macrael 8y agoYANWOT. Webs of trust are so obviously good, and yet so obviously have never really been implemented usefully.
- delinka 8y agoHow do these reviews and signatures get published? I'd love the ability to search by this extra metadata.
- mindB 8y agoThey get published per reviewer as a git repository on e.g. github, which is fine since you're not really supposed to be putting any value whatsoever on joe-random's reviews.
- sgeisler 8y agoImo this is the missing puzzle piece (and the more important one for me personally) for software supply chain security, the other ones being deterministic builds and signed binaries. And the real problem aren't even people trying to steal your bitcoins [1], you notice that and hopefully had not all your eggs in one basket, it's a (sometimes expensive) lesson in IT security. The much more serious threat are state level actors trying to backdoor secure communication channels, the breach will happen without your knowledge. One shouldn't expect that every nation will take the obvious and public route like the Australian government [2], simply demanding access. With enough resources it seems totally viable to backdoor just one deep dependency of some UI framework and circumvent all end to end encryption used by affected apps. I hope distributed code review will get some traction not only in the Rust world, but in the whole open source universe. [1] https://news.ycombinator.com/item?id=18534392 https://news.ycombinator.com/item?id=18534392 [2] https://arstechnica.com/tech-policy/2018/12/signal-to-australia-good-luck-with-that-crypto-ban/ https://arstechnica.com/tech-policy/2018/12/signal-to-austra...
- fearai 8y agoThis doesnt prevent trusted people from doing stupid things like this https://news.ycombinator.com/item?id=18534392 https://news.ycombinator.com/item?id=18534392 We need to trust the code not the programmer
- habitue 8y agoIt doesn't prevent anyone from doing anything. It increases the likelihood that if someone does something like that, that it will be detected. Crev seems interesting because it not only has the web-of-trust mechanic going on, but also because it creates an incentive to actually do code reviews on existing code. There's now a whole open frontier of "code that hasn't been reviewed in crev", which people might feel compelled to jump on. "Hey, my favorite crate isn't reviewed, I'll can do it". etc.
- dbaupp 8y agoI think crev is actually explicitly trying to establish trust for the code, not the programmer. > It protects against compromised dev accounts, intentional malicious code, typesquating, compromised package registries, or just plain poor quality.
- sgeisler 8y agoIt doesn't, but now both the original author and some number of independent reviewers have to do stupid things in order to cause harm. That's an improvement to the current situation where you mainly trust the author in most cases. A review is only valid for a specific version/hash of a set of files, so if you only upgrade your dependencies once they have enough trusted reviews you should be safe.
- edraferi 8y agoPretty cool. Long way to go, but great idea. I like this: > Design is open for supporting PGP, Salty, Keybase, and whatever else in the future. > Note: Systems like that don't carry enough information. Just because you verified that someones PGP really belong to them, doesn't mean you trust their code review judgment. But the identity/singing system could be reused.
- matthewbauer 8y agoIf something’s malicious, shouldn’t we just flag and remove it? Why is a concept of trust needed here?
- outside1234 8y agoWell, because that itself would become another attack vector. You need some sort of post-review after something is flagged malicious to prevent arbitrary take downs.
- TheCoelacanth 8y agoYou would, but that doesn't help you until someone figures out that it is malicious. This lets you track who has actually verified that the package is not malicious.