Cryptographically verifiable code review system for cargo Rust package manager | Hacker News Reader

Cryptographically verifiable code review system for cargo Rust package manager

github.com

95 pointspabs322 comments

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

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.

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.

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.

This is a solution looking for a problem to solve.

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.

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.

I would consider vetted vs unvetted to be a more important distinction than safe vs unsafe.

Rust has a trust model, and unsafe is an important part of that, but only a part. Unsafe means "the safety of this code relies on invariants not checked by the compiler." It does not mean "inherently unsafe." Rather, it means "trust must come from a different channel." This tool is providing such a channel.

If you want something that reports specifically on the use of unsafe code, then take a look at Cargo-Geiger.

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).

I'm not calling unsafe bad. I have no idea where you got that from.

I got it from your depiction of the actix kerfuffle. Maybe you didn't mean it, but all the original people involved who said similar things had very simplistic views of unsafe.

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.

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.

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

The concept is great, but the name is insulting.

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)

>but the name is insulting.

oh cmon

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.

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.

The Japanese word for "like" is the same as the Russian word for "bitches"

Not exactly, the Japanese word for "to like" is "suki", and there is also "soka" that means "I see". The Russian word for bitches is "suka". But yeah, I was confused at first when I started to live in Japan; they sound very similar, and even though I don't speak Russian, "suka blyat" is basic game slang nowadays.

I'm Russian ;) Suka is bitch, suki is bitches

You are right then. One of my life-long dreams is to learn the Russian language, but I never got the opportunity :(

Reply on news.ycombinator.com