Hi Robert! Sorry to read that you've lost your keys during upgrade - no chance to have a backup laying around somewhere?
You wrote: > 1) It presumes that any given login ID and key id uniquely identifies > a database. To whit > > mtn --db Employer1.db db migrate > mtn --db Employer2.db db migrate > > (== no more private key [EMAIL PROTECTED] from database Employer1.db) What would be interesting here is if mtn has warned you between the first and the second `db migrate` that there is already a private key in ~/.monotone/keys with the name "[EMAIL PROTECTED]" or if it blindly overwrote the "extracted" one from the first migration. If the latter is the case, I suspect this is a bug which should just be fixed. > 2) the mechanisms don't check they keystores for parity before doing > dangerous operations. > > mtn --db Employer3.db dropkey [EMAIL PROTECTED] > > Gee, the private key in .monotone/keys/[EMAIL PROTECTED] wasn't the peer > of the public key in Employer3.db, too bad, so sad. I'd consider this a bug as well. Apparently the signature of the public key in database is not compared with the one of the private key in keystore. But I'd have to have a look at the code before I can say this for sure. While I'd generally support the proposals from other people saying that some kind of <username>+<contractor> syntax should be used until mtn finally sorted the "keys are solely identified by their ID" issue out, there are other ways handling this issues in existing projects (this should then also avoid name clashes if revisions of two different projects suddenly arrive in one database and have been signed by equally named, but distinct keys before). So, another intermediate solution could be, f.e. to add a couple of ~/.monotone/keys/<projectname> directories and place the [EMAIL PROTECTED]'s in these subdirectories. Then, for each project workspace define your own _MTN/monotonerc and use the get_default_command_options() hook to prefix every command you're triggering there with a --keydir ~/.monotone/keys/<projectname>. You could also go the old unix route and just add a shell alias to separate those different keys / projects. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel