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

[Luke Kenneth Casson Leighton]

On Tue, Aug 27, 2019 at 10:05 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

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

that's even worse than i thought it would be.  that leaves no
possibility of independent auditing (you're saying that a *single*
person is now the point of failure), and almost certainly leaves it
vulnerable to a 2-stage compromise attack.

compare this to debian's procedures: the web-of-trust is itself a
package that is itself submitted via the same inviolate procedures
that all other packages go through.



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

how are the signing keys independently audited as trustable?

*are* the signing keys independently audited as trustable?


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

that now makes the git server a resource failure.  take down the git
server, and you just caused the entire network to fail.

debian does *NOT* do this.  there is absolutely *NO* dependence on
even the *existence* of network traffic.  or server names.

yet another serious design flaw.

are you starting to see how complex this really is?

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

GPG has key-signature revocation.  here is the procedure:
https://security.ias.edu/how-revoke-gnupgpgp-signature-key

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

which is simply not good enough.  another serious design flaw has been
identified.

what you're saying in effect is: all that an attacker need do is
arrange a DDOS attack against a server (or to hijack its DNS records)
or anything else that takes users into "offline" mode, and crev "falls
back" to a completely brain-dead and fundamentally broken "security"
mode?

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

so that's another serious design flaw (and, also, the idea that an
identity key is signed by an old identity - only - is itself a
security design flaw).

> though
> that may not be a problem if each key propagates trust independently. will
> have to check.

the design flaw that you missed was that by putting the "trust" repo
through the "system" as a secured package is: there are *independent*
checks - by *other people* - hard-coded into the chain.

you - the "signer" of the repo - are *NOT* the sole exclusive single
point of "trust".

the more that you're telling me about crev, the more alarmed i am becoming.

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

if any debian developer is caught doing that, they'll be expelled.
worse than that, the fact that they did so would be published widely
on the internet, resulting in the total destruction of their
reputation and career.

as it would be extremely high-profile, no employer would let them near
their systems ever again.  they would no longer be trusted - ever -
for the rest of their lives.

when an employer asked their peers for an endorsement, their peers
would refer them to the incident and to the key-revocation records.

doing something as stupid as letting other people have access to a
private key, when that person *specifically* went to the trouble of
showing GOVERNMENT ID, not just once but multiple times, is... i mean,
the thought of someone being happy with the consequences of sharing
their private key after going through such an identity-proof
procedure, they would actually have to be seriously mentally ill.


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

not good enough.  that's a really dangerous assumption.  that just
means that the gpg-clone signing system needs a full audit as well.

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

design of security procedures is unnnbelievably hard.  i *know* that
you're an intelligent, smart person, and yet you're making *basic*
fundamental security and security design assumptions!


> do note that even if crev turns out to be flawed, it's still waaay better
> than npm is right now

not really.  all that a flawed system does is deceive people.  this is
a recognised phenomenon in the Intelligence Community.

the intelligence community's worst nightmare is not that something is
insecure or secure, it's *not knowing* if something is secure or
insecure.

if they *know* that something is insecure, that at least allows them
to put mitigation procedures in place, and to deploy risk-value-threat
assessment processes.

if they *don't know* if something is secure or insecure then they have
to assume the absolute worst-case scenario.

this is *NOT* something that the average person can get their head
round.  the average person goes, "um, it might happen to me, but it
might not.  it's not happened to me, therefore it can't happen to me,
therefore i'm okay and can safely ignore the threat".

this is fine for when we were wandering through jungles and bashing
things on the head for food: it's where, from an evolutionary
perspective, our brains became hard-wired for a "lightning fast
reaction time" risk/threat assessment.

it's the complete opposite that's required for the kinds of scenarios
that global networked communication presents us with.


> (though I think they're finally supporting gpg
> signature checking soon).

that's a stopgap measure.  it'll do for now.

when people start talking about making it mandatory, the problems with
"just gpg signatures" will start to show up.

l.