Improving the trust model for commits

Matt Mackall mpm at selenic.com
Fri Apr 3 15:44:09 CDT 2015


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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list