[Monotone-devel] Re: mtn sign

[William Uther]

On 07/07/2007, at 9:00 AM, address@hidden wrote:

> I'm currently fiddling with the monotone source code to create a new
> command that allows me to re-sign revisions. At first glance, that  
> seems
> possible.

Sounds very possible, and a great idea...

> Why do I want to do that? Let's just say I did stuff when I wasn't  
> fully
> awake... as a result, I now have a number of revisions in my db  
> that are
> signed with a key that doesn't exist anymore. What's worse, I have  
> a key
> with the same ID in the db, so monotone (quite correctly) cries havoc.
> And, no, I don't have backups.

I ended up with the same problem after a new user did the same thing  
(two
keys, one ID) in my DB earlier this year.  My solution was to pull to  
a new DB,
and change epochs to stop the bad revs being pushed in again.  That was
far too extreme for normal use, and I expect this to be a not  
uncommon problem
with new users.

It is made worse if you use ssh based syncing.  Then ssh does the  
auth, which
means the signatures aren't checked before revs are sent around, and  
it is really
easy to propagate the bad certs.

> If you have any better idea than regenerating signatures with the new
> key for each revisions, I'd be glad to hear it. If not, is there any
> interest for a command like that to go into monotone? Any  
> preferences as
> to the specifics of this command?
>
> Personally, I'd go the simple/stupid way and would want
>
>   mtn sign <key id> <revision>
>
> overwriting any previous signatures for that revision in the db.

Looks like a reasonable solution.  You could probably already do this  
pretty easily at the moment - use automate to get the old certs, then  
re-sign with the new key.  That will add duplicate certs signed by  
the new key.  Then you sync the db to a new db, removing the old, bad  
certs.

Adding a new command to do it cleanly seems useful though.


This isn't the only approach however.  Graydon mentioned recently  
that he considered forcing all keys to have unique ID's to be a bug.   
If keys were referenced by hash instead then you could have multiple  
keys with the same ID.  That would seem to be a better long term fix  
for the problem (although I think the short term fix is also useful...).

Be well,

Will         :-}