[darcs-users] Re: signing of patches

[Anthony Towns]

David Roundy wrote:
> On Tue, Dec 07, 2004 at 03:25:12PM +1000, Anthony Towns wrote:
>>The other option would seem to be to include some md5sums of the patches

Or sha1 checksums, obviously. Silly habits.

>>themselves in the inventory, then sign that.  That'd let "darcs pull/get"
>>validate signatures too then. 
> I think this is the best way to go.  It is a useful feature even without
> signatures, as it allows us to catch things like proxies that modify the
> patch files in transit (as has happened before).
> 
> The trick would be that we'd have to either figure out a "hole" in the old
> inventory-parsing code where we could stick the patch hashes, or we'd have
> to have a repository format transition.

What about having "inventory.chk" files? If you try downloading it and 
it's not there, you've just got an unsigned/unchecksummed repository.

> Having patch checksums would also make it safer to reorder patches on a
> public repository, since anyone pulling would know if they got an
> inconsistent set of patches.  Currently only "unsafe" commands (unpull,
> unrecord, amend-record) modify patch files, but there are also features I'd
> like to add to optimize that would reorder patch files to make the
> repository more efficient.

You're thinking of what could happen if someone on a _really_ slow 
connection tried a "darcs get", and the admin ran "darcs optimize" 
between them getting the inventory and getting the actual files?

> If we're to have a repository format transition, we'd best do it right and
> figure out what all we'd want to add.  For each patch we'd want a hash, and
> then optionally at the end, we'd like a signature of the whole thing.  For
> a "continued" inventory, we'd probably also want a hash of the "Starting
> with tag:" inventory, so everything would be nicely daisy chained, and only
> the first inventory would need to be signed.

Hrm, do you need a hash of the "Starting with tag:" inventory, though? 
In the "normal" case, where you've already got the tag, you're just 
checking the email/log/date match, and assume you're fine; you don't 
actually check that your dependencies are what the remote repository 
thinks they should be.

The alternative (..that I can think of) is to sign each tag inventory 
separately. The only benefit would be that if you have "TAG A=S,T,U,V; 
TAG B=Starting with tag A:W,X; TAG C=Starting with tag B:Y,Z", then you 
wouldn't have to touch B or C's inventory if you wanted to change A to 
be S,U,V,T for some reason.

Hrm, actually, that /might/ suck a bit for darcshive -- if I've got two 
branches, X and Y which share a common "Starting with tag" A, and I have 
some cause to want to rearrange A, I'd have to re-sign both X and Y, 
rather than being able to just re-sign one file. There's probably 
nothing forcing me to do that rearranging though (I certainly don't do 
it atm).

>>	New patches:
>>	...
>>	Context:
>>	...
>>	[TAG ...
>>	...]
>>	Patch checksums: [for new _and_ context patches]
>>	1293412903412341aabceaba 123412
>>	....
>>	Inventory signature:
>>	...
>>	Patch bundle hash:
>>	...
>>you could recreate the original inventory file with checksums and verify 
>>the signature, then verify the new patches against the checksums, then 
>>commute and apply as usual.
> Hmmmm.  This no-signature-on-send trick would only work if you are sending
> all the patches in your repository, but it's still a pretty cute trick.

Yeah. It could be made to work for sending all-but-the-N-most-recent 
patches too, though there's probably no point to that.

> In general, you'd need to resign whenever you run any command that modifies
> the "recorded" state of the repository: record, unrecord, unpull,
> amend-record, rollback, tag, checkpoint (the checkpoint inventory would
> also need to be signed).  Then send would require a signature if you aren't
> sending everything you've got.

Apply and pull too, of course. Push too, kind-of, maybe, presumably.

Or you could arrange things so that:

	1$ darcs record -m 'blah'
	2$ darcs record -m 'blat'
	3$ darcs tag -m 'version 42'
	4$ darcs sign-repository

is entirely fine, and the fact that the repo doesn't have a signature 
until step 4 just means that "darcs pull --check-sigs" will fail.

Add "prefs/require-signature" to tell check-sigs to default to being on, 
and you've got a repository you can declare to be private or locked or 
whatever :)

Hrm. FWIW, for darcshive, I'd like to be able to extract the signature 
from a signed patch bundle, without having to use gpg etc, ie the 
reverse of the signed-repo -> signed-bundle transformation :)

Cheers,
aj