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

Jacob Lifshay programmerjake at gmail.com
Tue Aug 27 09:18:17 BST 2019

On Mon, Aug 26, 2019, 23:40 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> 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.
i did read about advogato a bit.

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

again, that would be more thoroughly verified when the security audit is

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

I think you are missing that the proof repo and the private keys are stored
completely separately: the keys would be on their owner's computer or
hardware key and the repo would (usually) be on a public server somewhere.
the server is not a very high-value target because even if an attacker
could put whatever they wanted on it, the only parts that other people
would trust are the parts that are also signed by the owner's crypto keys,
which the attacker doesn't have.

social engineering or lack of attention is generally not enough to get the
key owner to give out their private key, just like they wouldn't just pass
out their password to whoever asked.

the current version of cargo-crev encrypts the private keys by default,
requiring the owner to type in their passphrase to decrypt them in order to
sign trust records.

> 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

I'm well aware of how GPG is used in Debian and how everything is
recursively based on the web-of-trust.

I think crev is a good idea precisely because it is based on the same kind
of web-of-trust and similar signing mechanism, though, because it is
currently like an after-market addon for cargo, cargo doesn't currently
check everything that way when it's originally downloaded (since cargo-crev
isn't able to hook the download mechanism), instead, all the verification
and review-checking is done as a separate command (cargo crev verify, i

> 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.
debian's procedures are designed for a single organization, which is not as
practical for cases where there is no centralized place to store signatures
or Releases files. crev is similar, but more decentralized -- it doesn't
need a centralized package repository.

crev can handle those cases (though maybe not the current implementation).
crev should even be able to handle cases like, for example (currently only
works for rust crates and (maybe) npm packages), Khronos releasing a new
version of Vulkan, where Khronos is totally unaware of crev's existance.
people can still review a particular release of the Vulkan spec and publish
a signed review using crev, such that other people who download that
version of the spec can see that it has been reviewed by people that they
transitively trust, and crev will check that the cryptographic hash matches
the review.

> > 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.
that's true, however, any system that's supposed to improve security needs
to be sufficiently easy to use that most people will actually use it.

Having a safe in an armored truck is more secure than just putting your
stuff in a drawer in your house somewhere, but most people opt for the
drawer simply because it's easier and less expensive.

For me, at least, Debian's system is not easy enough to use for publishing
code, simply because I don't have a GPG key and am not likely to be able
get it signed by anyone in the Debian web of trust in the near future due
to not having met anyone in person (probably will change once I attend some

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

to be perfectly clear: i'm not saying that the person who wrote the wiki
page understood debian correctly or anything like that (they appear to only
be tangentially related to the crev project anyway, though I could be
wrong), I'm saying I think a lot of the ideas that went into crev are worth
having in whatever system ends up becoming standard for cargo, crev or


More information about the libre-riscv-dev mailing list