Improving the trust model for commits

Gregory Szorc gregory.szorc at gmail.com
Mon Apr 6 19:21:50 CDT 2015


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


More information about the Mercurial-devel mailing list