[libre-riscv-dev] web-of-trust for code reviews to manage trusting dependencies

[Jacob Lifshay]

On Mon, Aug 26, 2019 at 10:04 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On Tue, Aug 27, 2019 at 3:40 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> > I found a very interesting article about crev:
> > https://wiki.alopex.li/ActuallyUsingCrev
>
> oh look.  someone without a clue and who knows nothing of debian's
> distribution package management is endeavouring to re-learn basic
> web-of-trust chaining.  i wonder if there's a model that is already
> proven for 20+ years that works, or if there's anyone who knows about
> it and can describe it and how it works?

Before you dismiss it right away, crev can handle updates much faster
than Debian Stable.

One of the more important features that crev supports that I haven't
seen elsewhere is built-in code reviewing.

>From what I understand, it's primarily intended for avoiding malicious
code by allowing several people to review the same code and
independently sign it. Unlike how PGP is commonly used, crev allows
independent entities to review and attest to the quality or lack
thereof of the code and publish their results in a way that other
users will easily be able to use without the original authors needing
to do anything or being able to interfere in any way.

> https://slashdot.org/comments.pl?sid=14634346&cid=59120976
>
> oh look! there is!
>
> *face-palm*.... :)
>
>  "The Solution, Again? Nobody actually knows how to fix this."
>
> wronggg....
>
>
> "Will this web of trust model work? I don’t know."
>
> then why are you rushing to use it?

Because it sounds like a good idea and is similar enough to PGP's web
of trust that I think it will have mostly the same security
properties.

Also, I personally won't have any problems if it turns out to have an
implementation flaw before it's been verified to be correct, since I'm
not trusting crev as the sole source of truth to be correct until it's
been verified.

One part I particularly like about crev is that trust is based on the
combination of the proofs repo and the cryptographic signatures,
achieving something more like 2-factor authentication. This means that
an attacker has to both steal the private key and control the proofs
repo for anything they sign to be considered legit. This allows more
resilient recovery from private key compromise or proofs repo
compromise since no one will trust the fake signatures, either they
didn't come from the correct source or didn't have the correct
signature.

>
> oh dear.
>
>
> > It's basically making a web of trust to handle making sure that
> > dependencies are trustworthy.
>
> i wonder why that's occurred to people, only now?  whatcould they use?  hmmmm...
>
> https://en.wikipedia.org/wiki/Advogato
> https://tools.ietf.org/html/rfc2704
> https://wiki.debian.org/Keysigning
>
>
> > Note that using crev doesn't require GitHub, it just requires a public
> > git repo (the author doesn't use GitHub for their repo).
> >
> > There's currently only an implementation for Rust and Cargo:
> > https://github.com/crev-dev/cargo-crev
> >
> > This definitely needs to be integrated into pip, npm, and other
> > similar programs.
>
> nooo: it needs a full audit and secure-design review.  then and only
> then should it be considered for adoption.

Doing everything right away wasn't my intention, my intention was more
of that I think crev or something similar should be eventually
integrated into cargo, pip, npm, etc. since they are sorely missing
that functionality.

cargo-crev currently has a relatively easy to use interface.

Jacob Lifshay