Signing revisions in place
Matt Mackall
mpm at selenic.com
Wed Oct 3 17:39:20 CDT 2007
On Wed, Oct 03, 2007 at 02:50:45PM -0700, Jens Alfke wrote:
>
> On 3 Oct '07, at 1:49 PM, Dustin Sallings wrote:
>
> > It's unclear how you'd sign your own changeset in your changeset,
> > though. In the case of gnu arch, the signature was a separate file
> > from the patch tarball itself. If it's possible to do something
> > similar in mercurial, then it'd make sense.
>
> That's what I tried to describe in the email that started this thread...
>
> In a nutshell: When creating the revlog entry for a revision (the
> manifest hash + metadata + checkin comment), generate a signature of
> the entry and then append the signature to the entry, before adding it
> to the revlog. So in effect, every checkin comment would end with a
> bit of hex containing the signature.
>
> To verify the signature: Get the revlog entry corresponding to the
> changeset, cut out the last sizeof(signature) bytes, then validate
> that those bytes form a valid signature of the remaining bytes.
That turns out to be quite difficult structurally. Changelog entries
are stored in the same format as everything else: a revlog revision.
We don't know the hash identifier of the revision until we actually
try to commit it.
What we did early on was to sign the changelog description and the
associated manifest hash. This was a fairly ugly hack because we had
to intercede in the middle of the commit (between committing the
manifest and committing the changelog) and call out to GPG to do it.
And it leaves several parts of the changeset unsigned: user, date,
parents, and whatever junk we decide to stuff in extra (currently
branch name).
With the advent of the "extra" field, we now have a place to stash
other things in the changelog like a signature, but not an especially
good way of pre-hashing everything else. Fixable, I suppose.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial
mailing list