Improving the trust model for commits

[Matt Mackall]

On Mon, 2015-04-06 at 17:21 -0700, Gregory Szorc wrote:
> On Mon, Apr 6, 2015 at 4:04 PM, Matt Mackall <mpm at selenic.com> wrote:
> 
> > On Sat, 2015-04-04 at 10:59 -0700, Gregory Szorc wrote:
> > > On Fri, Apr 3, 2015 at 1:44 PM, Matt Mackall <mpm at selenic.com> wrote:
> > >
> > > > On Fri, 2015-04-03 at 12:53 -0700, Gregory Szorc wrote:
> > > > > People at Mozilla who write security and crypto code have approached
> > me
> > > > > about adding a stronger trust model to version control. tl;dr we want
> > > > > commit signing that establishes a cryptographic and distributed
> > (read:
> > > > > multiple signers) chain of trust that can be used to verify and audit
> > > > that
> > > > > changes to highly sensitive code are reviewed by the proper people
> > and
> > > > that
> > > > > changes land exactly as intended.
> > > > >
> > > > > I've put together
> > http://mercurial.selenic.com/wiki/CommitSigningPlan
> > > > with
> > > > > a proposed plan for a *supplemental* commit signing method to achieve
> > > > this.
> > > >
> > > > Interesting.
> > > >
> > > > (FYI, in the very early days of hg, I used to automatically sign all my
> > > > commits thusly: http://www.selenic.com/hg/rev/db3aa85b9379 )
> > > >
> > > > I think we need a more explicit list of the sorts of attacks we want to
> > > > defend against so that we can more explicitly define "what a signature
> > > > asserts".
> > > >
> > > > For instance, imagine Alice creates a large legitimate patch X. Eve
> > sees
> > > > an early version of patch X in flight and quickly submits a small
> > > > clean-up patch W that causes the final version of X to create a hole
> > > > when it lands. Now we have an attribution problem: Alice has asserted
> > > > that X is good, but if she's signing a delta rather than a full state,
> > > > her assertion can be made false between when she signs it and when it
> > > > lands. And Eve is in the clear from an auditing perspective: her patch
> > > > is demonstrably harmless.
> > > >
> > > > At some level, I think the best we can do is a chain-of-custody model:
> > > > each person/process validates the signature of the last person, and
> > > > creates a signature that asserts they have done that and the result is
> > > > changeset X.
> > > >
> > >
> > > I've made significant updates to the wiki page to address your questions
> > > and more.
> >
> > The big thing I'm skeptical about is how well your commit representation
> > is going to work in practice. I'm afraid that too many will become
> > invalid across rebase to be useful.
> >
> 
> Sure. However, perfection and 100% commit signing is not an explicit goal,
> at least at Mozilla. Instead, we want to look at enforcing signing on only
> a small set of highly-sensitive files. For this subset of commits, we'd be
> willing to trade convenience for better trust (and security).

I'd like something that the hg community itself could use. Which
probably means that we should be able to indicate _multiple_ _specific_
intents with a signature.

And I really really mean it when I say you have to spell out the
semantics of a signature's intent. It's not enough for something to be
signed. It has to say what the signature asserts, for instance:

- I wrote this commit and it has commit hash X and delta hash $X 
- I received an unsigned patch and audited it and committed it with hash
X / $X
- I received this patch and validated its signature and created commit
X'/$X'
- I validated commit X and rebased it to X'
- ...

Here's a more concrete example:

sig0: user=indygreg, source=author, abstract=1234abcd, delta=abcd1234, gpg-signature=sdfkjs...
sig1: user=pushgate, source=rebase, check-abstract=1234abcd, abstract=2345bcde, delta=bcde2345, gpg-signature=skdjjkd..
sig2: user=marmoute, source=import, audit=true, check-delta=bcde2345, abstract=3456cdef, delta=cdef3456, gpg-signature=ldlkfl..
sig3: user=mpm, source=rebase, audit=true, check-abstract=4567defa, abstract=4567defa, delta=defa4567, gpg-signature=oerituwow..

Note here that sig2 is making multiple simultaneous signed assertions:

- I got a patch and verified its delta $X
- I audited the patch
- the resulting commit abstract was X'
- the resulting delta abstract was $X'

Also note how sig1 gives us a chain of custody.. but doesn't assert that
it actually read anything because it's an automated process.

We can also imagine the following for an unsigned patch that we decide
to sign in review (perhaps because it came from an anonymous security
researcher):

sig0: user=durin42, source=import, audit=true, abstract=3456cdef, delta=cdef3456, gpg-signature=ldlkfl..
sig1: user=mpm, source=rebase, audit=true, check-abstract=4567defa, abstract=4567defa, delta=defa4567, gpg-signature=oerituwow..

So a verifier will need to distinguish between audited-to-standard-X and
verified-to-originate-from-Y and both-verified-and-audited.

-- 
Mathematics is the supreme nostalgia of our time.