[Monotone-devel] A newby's tale

[Peter Stirling]

Hi!

I'm a new user of monotone, I first used cvs then svn, but I got fed up 
with how problematic they were when you wanted to work on two
computers when mostly they weren't on at the same time, or unable to 
connect to each other over the internet. The monotone workflow
seems ideal for my purposes, and I've been playing with it for a couple 
of weeks with some 'toy' projects to learn more about it.

I started with a single project and I chose a setup as suggested with 
the tutorial (ie password for private key, and using ssh-agent) and
things were fine until a few days later when I rebooted my machine and 
it started prompting for a password and wouldn't take the password
I thought it was.

After abandoning my attempts to remember the password, I tried to 
generate a new key with the same name, only to be told that a key with
that name already existed.

Examining the documentation led me to 'mtn dropkey', who's warning I 
ignored (What further harm can it do? I can't sign certs with the key
anyway).

	I would suggest that the documentation be changed to make explicit 
that the dropping of a public key invalidates 	EVERY EXISTING REVISION 
signed with that key, as opposed to merely disabling you from signing 
new certificates with it (which
         is all I thought it would do).

After producing a repository that would generate warning messages on 
every command applied to it, I worked out that if I could somehow
resign all the existing now-invalid certs. So, I wrote a python script 
to do that for me, by reading the list of keys which had 
'private_location'
fields (via 'mtn au keys'), then finding all the revisions signed by 
each key from that, then listing all the certs to find ones who's 
'signature'
is returned as 'bad' for which there isn't an otherwise identical cert 
which is 'ok'.

Would this be useful to others? I looked at the list archives I saw 
that the issue of lost key-passwords had been brought up before but I 
didn't
see any mention of a solution (though perhaps I didn't look hard 
enough). I also thought that something like this would be useful for
situations where a private key is compromised (and you had the 
potential for someone hostile signing bogus revisions with it).

I'm not sure what the 'correct' thing is to do with the bad certs, 
monotone doesn't seem terribly happy with them still in the database 
(at least
 as far as 'mtn db check' is concerned), but silently deleting them and 
pretending that the new certs were always there doesn't sound like the
 sort of history operation that a version control system should be 
doing either. Ultimately I suspect some sort of 
'I want to change my key'
command will be required that allows you to record a key change (and 
requires the permission of anyone who recieves such a request via
a 'push')

Peter