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