Improving the trust model for commits

[Alex Orange]

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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150617/9da90e26/attachment.html>