[libre-riscv-dev] web-of-trust for code reviews to manage trusting dependencies
programmerjake at gmail.com
Tue Aug 27 10:05:19 BST 2019
On Tue, Aug 27, 2019, 00:31 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> 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
> 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
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
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
> 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
> ...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
> 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.
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.
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev