Cryptographically verifiable code review system for cargo Rust package manager

by pabs3 • 5 years ago

95 22 5 years ago

j16sdiz• 5 years ago

This is a solution looking for a problem to solve.

c7DJTLrn2• 5 years ago

Disagree. One of the big selling points of Rust is the safety guarantees you get unless you use the escape hatch, which should only be used conservatively. When you add third-party code, you are trusting that the maintainers of that code have only written unsafe code where necessary and that the unsafe code is correct.

A few years ago, everybody suddenly realised that one of the big Rust HTTP libraries was full of unsafe (incorrect) code and went on a crusade to fix it. Up until that point, nobody had properly vetted it and took its lofty performance stats at face value.

hvdijk• 5 years ago

Sure, but cargo-crev does not seem to be about safe vs. unsafe code, it seems to be about vetted vs. unvetted code. If someone will go on to wrongly vet a big Rust library full of unsafe code, and you trust that someone's reviews, there still won't be anything that tells you of the unsafe code, if I understand correctly.

iudqnolq2• 5 years ago

Safe: Command::new("rm").args(&["-rf", "/"]).spawn()

Unsafe: unsafe { 1 + 1 }

Unsound: unsafe { &mut *(&1 as *const _ as *mut _) }

Edit: Importantly, the non-unsafe example I posted also calls a bunch of unsafe code, as is necessary to do anything nontrivial (see https://github.com/rust-lang/rust/blob/master/library/std/sr...). My point is that safe-good unsafe-bad is the wrong way to think about things. This is why you see experts on this (which I'm absolutely not) refer to unsafe code that violates the Rust Memory Model™ as unsound. (You may also find the fact the Rust Memory Model is more of a vibe than a standard surprising. How do you write sound code then? Try reasonable things and hope the compiler agrees with your definition of reasonable).

throw4738• 5 years ago

With Java code I get notifications on github about unsafe libraries. I also have tools to verify my dependency tree.

In new platform, this would be one of first tools, I would seek.

rcxdude• 5 years ago

This is a problem frequently complained about with language package managers: huge amounts of unvetted code which is just pulled in without being reviewed. This allows the work of vetting the code to be distributed and used by the average developer.

jedisct1• 5 years ago

To a French speaker, the project name sounds like “Go kill yourself” (creve).

The concept is great, but the name is insulting.

littlestymaar• 5 years ago

Well, that's pretty far fetched (and btw, in French the word «crever» isn't an offensive one in the general case: «Je suis crevé» means “I'm exhausted”, and «une roue crevée» is a flat tire)

tester34• 5 years ago

but the name is insulting.

oh cmon

nh2• 5 years ago

To a French speaker, the car "Audi e-tron" may also sound weird, given that étron means "turd". Yet it is marketed that way.

Perhaps people start to make piece with the fact that some words come from other languages, and that one doesn't have to search for the insult in every crevice.

dbrgn• 5 years ago

There are more examples.

Mitsubishi Pajero is called Mitsubishi Montero in some spanish-speaking countries since Pajero means "wanker".

In Switzerland, Nestlé rebranded their "Fuze Tea" to "Fuse Tea" since if you pronounce it in Swiss German it sounds like "cunt tea".

The website generator "Wix" just went ahead with their name (which means "to wank" in German) and actually made some pretty nice ambiguous/suggestive German "banned ads" about it.

hoophoop• 5 years ago

This is what [big] Linux distributions are for: vetting packages and vetting the vetters.

orta• 5 years ago

Crev is a very cool idea, if I was building a new dependency manager - I'd look into integrating something like crev as early as possible.

TrueDuality• 5 years ago

It's interesting but I'm not sure how I can trust the "web-of-trust" here. Traditionally web-of-trusts are built using real world relations. I've worked with person X for 5 years and I believe they wouldn't do something malicious, so I'm willing to trust sources they trust. It starts with trust us, and trust every username in this preloaded file we want to give you. That's not distributed, that's a centralized trust model.

The trust boundaries themselves seem pretty broad as well. I may trust some developers to work on any code, but I may not trust them to review any code. A good example is anything relating to cryptography. I trust X to write that code as long as its been reviewed by expert Y, but I don't trust expert Y to review code in specialized field Z. A lot of this will come down to personal judgement.

The "web-of-trust" model itself here also seems pretty limited. There is mention of a form of trust decay but its not clear how or when that happens, and its not clear what the trust levels mean in this app. What is "medium" trust of a developer? How does that impact whether code is considered reviewed or not? What happens when a developer two-degrees away from me adds someone malicious? Are they also getting the medium trust level? What if I explicitly _don't_ trust a developer that is directly listed in crev's root of trust repository? Can I add them to an ignore list?

I might have missed it, but this also seems to be positive trust only. I can't see a way to publish a proof saying "whhoooaaa this crate is actively malicious stay away from it".

Based on the getting started guide, the way this project is meant to be used is to start by trusting their central root of trust. If they want to expand on that they can create their own trust repository and start adding to it, inside an organization you can give your team access to modify the repo and you can now trust what your colleagues have reviewed. That's it though, that review process never feeds back into the community. The web-of-trust here is a hierarchy unless someone is blessed by the central repository to become part of their core trust. This model isn't distributed at all.

"Wanting" a discovery, or actual web mechanism here may seem counter-intuitive with my first point but can provide important information without inherently trusting individual reviews. If a package has 20 independent reviews and a competing version of the package has none, I still don't know anything about the code or its quality, but I will lean more towards the one that has been reviewed. There is a wiki-page people can publish their proof repos there, but the only way to consume them is to add them to your trust network...

Ultimately I think the problem is that while it can operate in independent trust networks, it's effectively been designed with a centralized trust model that I have no way of trusting and no way to establish that trust. I can't even use these proofs as metadata when deciding on dependencies to use in the future. There isn't any value add here as it stands.

RhodoGSA• 5 years ago

Yes, some malicious actor could infiltrate the network theoretically. However, the point here is to have some 'oracle' or data point into the security of the broad array of crates/packages available.

Cryptographically verifiable code review system for cargo Rust package manager

Related Stories