Improving support for signed revisions

Arne Babenhauserheide arne_bab at web.de
Mon May 11 01:21:59 CDT 2009


On Monday, 11. May 2009 07:59:15 Peter Arrenbrecht wrote:
> > More exactly: You need to include all data which you want to verify (or a
> > hash of it) into the signature.
>
> Remember that the changelog "text" contains all of:
> - manifest hash
> - changelog message
> - committer name
> - commit date
...
> So all you could do is commit another identical version of all the
> files, with identical commit message, but with a different reported
> ancestry in the changelog (but not in the manifest or file logs).

I confused changelog text and message... Many thanks for clearing me up! 

This might even be preferable to signing the revision itself, because rebasing 
and similar won't invalidate the signature, so one single changeset is always 
valid. 

So the only attack I can imagine is that someone might rewrite history to make 
the changeset affect data it was never intentioned for which could in turn do 
nasty things (which would be attributed for its signer then, and not to the 
forger). 

> To plug this last hole, you would simply sign both the changelog text
> (as opposed to changelog message) plus the two changelog parent ids
> (much like the final hash does, although the latter will then include
> the signature in the text it hashes).

Jupp. That should fix the forging hole. 

Thanks for the clarification! 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090511/84c6a14a/attachment.pgp 


More information about the Mercurial mailing list