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

[Jacob Lifshay]

On Tue, Aug 27, 2019, 00:31 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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.
>
crev has a separate proof repo for each key owner. the idea is the person
signing the proofs is the one who owns the repo.


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

for crev, the signing keys are only on the developer's computer (or other
device used for signing), not the git server.

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

crev associates your identity with the git server and signing keys, which
is very similar to how Debian does that. there very well can be crev
key-signing parties exactly the same way as GPG.

crev supports a trust level where no trust is implied, merely to inform
others that a key exists.

crev also has a negative trust level, where someone can distrust someone
else -- I don't think PGP has that, though I could be wrong.

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

I think crev does support a offline mode, it just removes the proof-repo
location verification and keeps the signature verification, so the security
goes back down to GPG's level.

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

I think there might be a problem in the current implementation where a new
identity key isn't required to be signed by an old identity key, though
that may not be a problem if each key propagates trust independently. will
have to check.

>
there isn't a centralized trust repo. each owner has their own repo which
(I think) is only allowed to contain items they signed. so, potentially, a
repo owner could add a key with their identity but let someone else sign
stuff with it, but Debian's system has the same problem of someone creating
a gpg signing subkey but letting someone else have it, allowing
impersonation.

from what I can tell, the proofs repo is a layer built on top of the
already secure gpg-clone signing system, so it just adds additional
security.


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

yeah.

do note that even if crev turns out to be flawed, it's still waaay better
than npm is right now (though I think they're finally supporting gpg
signature checking soon).


> then they will have a full appreciation for why debian's process takes
> some time.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>