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

[Luke Kenneth Casson Leighton]

ok, so the key thing in distribution trust chains is that not only
does there have to be a mathematically-inviolate way of linking each
stage together, there needs to be some thought put into discouraging
or mitigating "people-based" and "resource-based" vulnerabilities at
every step of the way, as well.

so for example "i have a great idea!  let's make a proof repo!  i will
be the sole exclusive person to manage it! you can all trust me!" is
clearly and obviously dumb... but *only* because i've gone to the
trouble of making the mistaken assumption plainly obvious.

the mistake that the morons behind Mozilla's B2G (failed, thank god)
effort made was to go "i have a great idea!  let's make SSL the way to
do repo distribution!  let's use SSL certificates so that people can
trust them!  let's host the SSL certificates on servers!"

which now makes the servers - and the certificates on them - a
high-value hacking target.

debian's process - which has nothing to do with debian itself - has
gone to a *lot* of trouble to ensure that there are no single-person
or single-resource targets, *particuarly* networked single-resource
targets.

where it is absolutely essential that an individual be trusted, then
instead they use "social engineering" to ensure that the person's
identity is inviolately known to as many other individuals as
possible.

this is what the key-signing parties are for.

once the person's identity is inviolately-known, that person's
*personal reputation* is now at stake if they screw up.  there is
therefore a strong incentive fo them to not do so.

there are actually something like *four* stages (possibly more) in the
process that was invented by debian, and at each stage there are
*different* teams involved (which, again, means that no one person -
and their keys - become a high-value target).  each team is
responsible for a different phase of the release process, and it
involves GPG-signing of SHA secure checksums of the files involved in
the previous stage.

*at no time* is a person allowed to become "trusted" just because
their friends arbitrarily said so.

[Advogato was specifically designed to highlight the problem of "trust
spam attacks", where through sheer quantity of "trust me, trust me!"
spammers, who set up friends, then friends-of-friends, all of whom are
automated bots, the actual web-of-trust is overwhelmed, making it
impossible to detect actual trustworthy people]

*at no time* is there a hard-critical dependency on any individual person.

*at no time* is there even a hard-critical dependency on any given
networked resource.

in fact, *the entire process* may be done offline (courier pigeons or
hand-to-hand file transfers) right from the actual source code all the
way to the actual installation by the end-user...

... *and the end-user can still verify it*.   all without needing any
kind of network resource.  they can start from a SHA256 checksum and
go from there.


another factor which is critically important: the actual web-of-trust
itself needs to signed and distributed through the exact same
mechanism that protects all other packages.

in other words, the web-of-trust needs to be treated *as a secured
distributed package*.

is the crev "trust" repo distributed as a secured package?

or did they just blithely go "hey guys!  you can use the trust repo
for aaaalll your trust needs!  all you need to do is a git pull! and
you know you can trust git and ssl, right? and you know you can trust
meeee to not take a bribe to insert compromised certificates in here,
right?  right, guys?  i'm totally trustworthy, come on! trust
meeeeee..."

...they forgot to secure the actual trust repo from both social
engineering and resource-attacks didn't they?

once you have that web-of-trust repo *as* a package, it can be
"upgraded" in a trustworthy manner.  why? because the revised version
is ALSO CHAIN PROTECTED... and not by the people who last did a "git
commit", either.


from what i can see of crev, by failing to understand the debian
distribution process, they've not bothered to think through the
absolutely crucial social engineering attack vectors.

they've just dismissed the entire lot, and that to me is an instant
red flag.  if they cannot do a proper formal side-by-side review of
something that is known to work, their entire methodology is INSTANTLY
suspect.

right there in the README (https://github.com/crev-dev/cargo-crev)
there's absolutely no links to whitepapers, no links to design
documentation, no links to reviews, no links to design reviews or
design discussions.

they've just blithely jumped right in and gone "hey guys here's some
code - you can trust it, because we said so".

...you see how that doesn't work?

basically, yes: the problem exists, has done for over a decade: it's
only just now got some "attention" because these unprotected packages
are now high-value targets.

is crev a good solution? given that they haven't bothered to do the
research, and have dived straight into an implementation, the answer
has to be no - and that has absolutely nothing to do with how good the
code is, or whatever good ideas they've put into it.

*when* they've done the research, and carried out a proper
comprehensive formal side-by-side evaluation of *all* package
distribution systems out there (the good ones, the mediocre ones with
flaws such as archlinux, and the downright dangerous and stupid such
as npm and Mozilla's B2G), and *when* they can tell people like me why
ubuntu has flaws that debian does not (even though they use the exact
same code and the exact same process), *then* i'll have the confidence
that they know what they're doing.

then they will have a full appreciation for why debian's process takes
some time.

l.