Signing revisions in place

[Dustin Sallings]

On Oct 3, 2007, at 13:33 , Jens Alfke wrote:

> That's also useful, agreed, and it's more like the way the gpg  
> extension works. I'm not sure quite how a tag is implemented — is  
> it similar to a child revision, under the hood? If so, the same  
> technique I proposed would apply.

	Tagging is *theoretically* just a change to the tags file.  In  
practice, it seems more magic than that (see what happens when you  
tag in one head while working in another, and then try to update to  
that tag).

>>  gnu arch allowed one to sign each revision.  I'm not sure if  
>> that's generally valuable here
>
> I think it is; the more so, the more paranoid you are :) or if the  
> project belongs to an organization that wants to know exactly who  
> commits (or to restrict who can commit into important  
> repositories.) There have also been cases where open-source  
> projects were compromised by maliciously-introduced changes that  
> opened security holes; I remember cases of this in both WordPress  
> and the Linux kernel. Signatures can make it possible to guard  
> against that.

	Yes, that is a good use case.  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.

>> but if one could be confident in a signature on a revision hash,  
>> and confident that the correct tree could be generated from that  
>> hash, I think the solution is pretty solid.
>
> The manifest hash identifies every file, its contents and ancestry.  
> SHA-1 isn't the best hash out there, but it's still considered  
> "pretty good", and used for a lot of secure systems.
>
> Generating the tree from a hash is impossible, though. Hashes are  
> by design one-way, and in any case the hash only holds 160 bits of  
> information, which is orders of magnitude smaller than any source  
> tree! But of course one can verify the authenticity of a revision  
> from an authenticated manifest hash.

	I phrased that poorly.  I didn't mean to imply that mercurial has  
the most awesome compression ever.  :)

	I have damaged repositories such that they worked, but some earlier  
revisions were unavailable.  Things like that make me nervous.  I'd  
much rather have it just stop working at the point where I've damaged  
it (or perhaps have a verify fail).  Oddly (thankfully), I can't  
reproduce the verify failure now.

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20071003/2309a76f/attachment.htm