
Crev: dependency vetting with a web of trust - mindB
https://github.com/dpc/crev
======
pornel
Some 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
I'm pretty sure the left-pad crate is a joke. That functionality is in the
standard library...

~~~
tln
The only dependency of left_pad:

[https://crates.io/crates/kik](https://crates.io/crates/kik)

"waiting for a takedown notice :P"

~~~
richardwhiuk
That's not a dependent on left pad, that's something which depends on left
pad.

------
kuhhk
> 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
"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.

------
sgeisler
Imo 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-
austra...](https://arstechnica.com/tech-policy/2018/12/signal-to-australia-
good-luck-with-that-crypto-ban/)

------
mindB
There'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.

------
edraferi
Pretty 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.

------
tln
This 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.

------
weinzierl
> Trust is fundamentally about people and community

This is so important. We souldn't trust packages but the people that assume
responsibility for them.

------
fearai
This 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
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.

------
3pt14159
YES! 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.

------
macrael
YANWOT. Webs of trust are so obviously good, and yet so obviously have never
really been implemented usefully.

------
z3t4
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 ?

~~~
riffraff
Who would trust those?

~~~
z3t4
Then the question becomes, how do you know who to trust ? Are you supposed to
also vet the id-hashes of the signers ?

~~~
sgeisler
I 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.

------
delinka
How do these reviews and signatures get published? I'd love the ability to
search by this extra metadata.

~~~
mindB
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.

------
matthewbauer
If something’s malicious, shouldn’t we just flag and remove it? Why is a
concept of trust needed here?

~~~
TheCoelacanth
You 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.

------
alexchamberlain
It would be really cool if this could express claims about copyright and
license, as well as code quality.

~~~
mindB
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?

~~~
fiddlerwoaroof
It would be useful to know if the MIT library you’re depending on pulls in a
AGPL transitive dependency.

~~~
mindB
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.

------
awinter-py
trust networks for software supply chain, love it

