Signing revisions in place

[Daniel Holth]

Matt Mackall wrote:
> On Wed, Oct 03, 2007 at 11:39:04PM -0700, Jens Alfke wrote:
>   
>> On 3 Oct '07, at 3:39 PM, Matt Mackall wrote:
>>
>>     
>>> 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.
>>>       
>> You don't need the hash of the *changeset*, just of the manifest. And  
>> that's already contained in the body of the revision entry.
>>
>>     
>>> 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.
>>>       
>> Yeah, I can see why that would be sub-optimal. Hm. :-/
>>
>> Would it be possible to generate the signature earlier, by *computing*  
>> the hash of the manifest before actually writing it out? So the  
>> sequence would be: get commit message, compute manifest hash, sign  
>> revision data, write manifest, write changeset.
>>
>>     
>>> And it leaves several parts of the changeset unsigned: user, date,
>>> parents, and whatever junk we decide to stuff in extra (currently
>>> branch name).
>>>       
>> My proposal signs the entirety of the changeset.
>>     
>
> If the signature is part of the changeset, that's a bit challenging.
>
>   
I thought one might write out the changelog entry without the signature, 
sign that, and then add the signature to the extra dict. To verify you 
remove the signature from the extra dict in a predictable way. That is 
why the extra dict must be sorted before it is written out. So this is 
the same ugly intercession alluded above?

I thought the extra dict was sorted already but I don't see it in 
changelog.py:encode_extra().