How does Crev's web of trust work !? What if the malicious user creates a bunch of fake id's to sign the compromised code ?
Who would trust those?
Crev: dependency vetting with a web of trust
21–30 of 43 posts
Re: Crev: dependency vetting with a web of trust
#22Imo 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
[2] https://arstechnica.com/tech-policy/2018/12/signal-to-austra...
Re: Crev: dependency vetting with a web of trust
#23How do these reviews and signatures get published? I'd love the ability to search by this extra metadata.
They 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.
Re: Crev: dependency vetting with a web of trust
#24> 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 in…
"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.
Re: Crev: dependency vetting with a web of trust
#25Earlier quoted context omitted.
Could 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?
It would be useful to know if the MIT library you’re depending on pulls in a AGPL transitive dependency.
I 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.
Re: Crev: dependency vetting with a web of trust
#26Re: Crev: dependency vetting with a web of trust
#27This doesnt prevent trusted people from doing stupid things like this https://news.ycombinator.com/item?id=18534392
We need to trust the code not the programmer
Re: Crev: dependency vetting with a web of trust
#28This doesnt prevent trusted people from doing stupid things like this https://news.ycombinator.com/item?id=18534392 We need to trust the code not the programmer
It 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.
Re: Crev: dependency vetting with a web of trust
#29This doesnt prevent trusted people from doing stupid things like this https://news.ycombinator.com/item?id=18534392 We need to trust the code not the programmer
I 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.
Re: Crev: dependency vetting with a web of trust
#30Pretty 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.