Improving the trust model for commits

Thu Jun 18 23:05:00 CDT 2015

On Wed, 2015-06-17 at 21:51 -0600, Alex Orange wrote:
> I found this while trying to do some work on a buildbot sign-off system so
> I'd like to drop my two cents in as well as ask what the status of these
> proposed changes are.

Purely theoretical at present.

> My use case of such a system would be to prevent code being pushed into a
> certain repository (namely the official repo for a given project) without
> first being tested. Mainly this would be to avoid whoops cases but it could
> also be used to avoid nefarious purposes. Certainly build hooks could be
> used to avert the whoops case by using precommit and to handle the
> malicious case prechangegroup each of these hooks doing some sort of
> testing (such as with buildbot). This of course could take a significant
> amount of time to run all of the tests (mercurial testing is a good
> example), inconvient for precommit and likely intolerable for
> prechangegroup.
> 
> My idea is to simply have the buildbot sign-off on a commit and then have
> the appropriate hooks check that such a sign-off exists. In order for this
> sign-off to be canonical the sign-off would have to be with respect to both
> the diff and the parent. There would likely be two useful kinds of testing
> sign-off as well. One for when the patch is initially submitted and being
> reviewed with sufficient meta-data to show what revision the patch passed
> tests relative to. The other being just before push to the official
> repository to prove that it passes tests with respect to its latest parent
> (if for instance rebasing has occurred since the last test). It sounds like
> mpm already wants this "complete commit" signing, but I don't seem to see
> where this is indicated on the wiki.

Yeah, I haven't updated the wiki to match my proposal.

> TL;DR: Another use case for sign-off: buildbots.
> 
> P.S. I'm very interested in this functionality and wouldn't mind putting in
> some time on it. Is anyone working on this at the moment?
> 
> On Tue, Apr 7, 2015 at 3:50 PM, Matt Mackall <mpm at selenic.com> wrote:
> 
> > 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.
> >
> >
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at selenic.com
> > http://selenic.com/mailman/listinfo/mercurial-devel
> >

-- 
Mathematics is the supreme nostalgia of our time.