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

[Luke Kenneth Casson Leighton]

On Tue, Aug 27, 2019 at 6:51 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> 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.

of course it can!  that's a completely unfair and absolutely
unrealistic comparison.  debian/stable has some very specific
criteria, namely that it has over 10,000 people test it for several
months, to ensure that an apt-get dist-upgrade from stable to stable
release will work, guaranteed.

people unfamiliar with debian simply do not understand that you
*never* go "just" with debian/stable.  the procedure is as follows:

* base install: stable.
* if this does not do what you want, add security/updates.
* if this does not do what you want, and you need to keep the
long-term upgrade path, add stable/backports
* if this does not do what you want, and you need to keep the
long-term upgrade path, add debian/volatile.
* if this does not do what you want, and you do not need to keep to
the long-term upgrade path, add debian/testing
* if this *really* does not do what you want, add debian/unstable
* if *THAT* really does not do what you want, add debian/experimental.

by the time you get to debian/experimental, you're at the absolute
ragged edge of what's uploaded by (over 1000) maintainers.
debian/unstable is delayed from debian/experimental by two weeks, to
at least give some kind of testing time.


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

that's a good "feature" - it doesn't mean that the rest of the design
- the actual chain of trust - actually works.

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

have a look at why advogato was created.


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

again: have a look at why advogato was created, and why and how
debian's web of trust actually works.


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

not good enough.  "mostly" the same security properties is simply not
good enough.

to give you an example: i reviewed microsoft's NTLMSSPv2 algorithm at
the request of paul leach.  he claimed it was 128-bit safe.

the algorithm was MOSTLY 128-bit data-paths... oh and then right in
the middle there was a 64-bit computation.

it is ESSENTIAL that a web of trust be used RIGHT the way through.
there is no room for "mostly".


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

you aren't... other people might.


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

that makes the proof repo a high-value target for attackers.  and
social engineering or simply plain lack of attention is easy enough to
result in keys being stolen.

have a look at how debian's distriibution chain actually works - and
why it works.  i describe it here:
https://it.slashdot.org/comments.pl?sid=14123270&cid=58732570

so, nope - not impressed.

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

yes, they are.  i've written about it several times.

the security-ignorant kiddies have gone "oh look, debian's shit
because it's so slow to update, let's throw out the entire fucking
process which makes debian immune to attack".

i've been trying to point out for about 5-10 years now the risks
associated with ignoring debian's procedures.

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

that's missing the point, and is in danger of being misleading.  the
absolute most important thing is to *understand what makes a secure
chain*, first.

*then* you design the interface around the basic fundamental concepts.
if the interface happens to be easy, that's _great_... but it's
absolutely essential that simplicity *not* be a driving "priority one"
factor.


> One other part that's different than Debian is crev is designed to be
> mostly independent of the actual method of publishing the code that is
> being reviewed. This allows adding web-of-trust based code reviews to
> be done and can handle cases such as someone compromising an account
> and publishing their malicious code, since all that's needed is for
> someone who you transitively trust to review the code and find it to
> be malicious.

it's extremely easy to replicate the process behind debian's inviolate
distribution chain.  first you have to understand it.
https://it.slashdot.org/comments.pl?sid=14123270&cid=58732570

that process is *not* tied specifically to debian.  it's just that
debian has *implemented* an inviolate distribution-chain-system.

this is what particularly pisses me off when i see these "let's
reinvent the wheel" posts, particularly ones that criticise debian
*without reviewing the process* and instead conflating the two and
making logically-false claims.

l.