News for hackers. Stuff that matters.
Re:Crev: dependency vetting with a web of trust by pornel on Friday January 04, 2019 @11:50AM (#18825452)
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 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.

Re:Crev: dependency vetting with a web of trust by eridius on Friday January 04, 2019 @05:20PM (#18828258)
> 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).

Re:Crev: dependency vetting with a web of trust by nicoburns on Friday January 04, 2019 @12:59PM (#18826105)
I'm pretty sure the left-pad crate is a joke. That functionality is in the standard library...
Re:Crev: dependency vetting with a web of trust by tln on Friday January 04, 2019 @01:32PM (#18826436)
The only dependency of left_pad:

https://crates.io/crates/kik

"waiting for a takedown notice :P"

Re:Crev: dependency vetting with a web of trust by richardwhiuk on Friday January 04, 2019 @07:01PM (#18828936)
That's not a dependent on left pad, that's something which depends on left pad.
Re:Crev: dependency vetting with a web of trust by reindeerer on Saturday January 05, 2019 @02:55AM (#18830522)
Moxie Marlinspike came up with the concept of trust agility some time ago. I think it's imperative that the agility of the trust network is guaranteed, because this can be a fast changing situation.
Re:Crev: dependency vetting with a web of trust by stcredzero on Friday January 04, 2019 @07:29PM (#18829041)
Cargo 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.

Re:Crev: dependency vetting with a web of trust by jake_the_third on Saturday January 05, 2019 @12:01AM (#18830002)
> only centralized webs of trust work

How can you claim that? Looking at most tech we have today, it becomes readily apparent that most technology needs multiple iterations before achieving wide adoption. Web of trust is no exception.

The lack of a widely-adopted precedent implying that some tech is forever poor is a sloppy conclusion to make.

Re:Crev: dependency vetting with a web of trust by stcredzero on Saturday January 05, 2019 @04:01PM (#18834225)
The lack of a widely-adopted precedent implying that some tech is forever poor is a sloppy conclusion to make.

Yes, but decentralized webs of trust have been tried before, and the "flat" ones with no centralization fade away or become hipster tchotkes. I think it's a valuable question to ask. Have we done the analyses for why the previous ones didn't work?