Richard Levitte - VMS Whacker wrote:
In message <87pt4uxrm9.fsf@xxxxxxxxxxxx> on 10 Sep 2004 13:58:38 +0200, Peter Simons
<simons@xxxxxxx> said:
simons> | [...]
simons> | monotone: connecting to venge.net
simons> | monotone: [bytes in: 564] [bytes out: 733]
simons> | monotone: warning: key 'derek@xxxxxxxxxxxxx' is not equal to
simons> | key 'derek@xxxxxxxxxxxxx' in database
simons> | monotone: [bytes in: 612] [bytes out: 770]
simons> | monotone: read from fd 7 (peer venge.net) closed OK after goodbye
simons>
simons> What does this mean? How do I handle this "key change"?
It means that different databases have different keys named
'derek@xxxxxxxxxxxxx'. I think Derek said earlier that he had done
some key change, or something like that.
I noticed this the other day as well... graydon's database ended up with a bad
key from me which I initially generated when I first got going with monotone.
There is nothing in the database signed by this key.
Graydon and I did sort this out the other day and his database now has my good
key.
To fix the problem you need to delete my old public key from your database.
$ monotone db execute 'delete from public_keys where id = "derek@xxxxxxxxxxxxx"'
Then sync with graydon and you should be good.
I'm probably partly to blame, as I joined together the data from
Graydon's and from Derek's servers, and got one of those keys while
Graydon got the other, or something like that... Gah...
It's mostly my fault I think... the first key I generated managed to get out and
I hadn't intended that. When I got around to generating a "real" key I noticed
the problem.
I'll dig a little in my databases and see if I can do some kind of
recovery that removes this mess.
I take it as an indication that key handling needs to be altered.
Quite possibly. ;) I wasn't all that careful when I generated my first key and
it had a particularly bad passphrase. I ended up deleting the database that
contained it and starting over while being more careful.
For the record my "good" public key is;
[pubkey derek@xxxxxxxxxxxxx]
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDACq6E1Dm1CXq7czaZo4/ycKgqQShewclx
HAcweq0imG/NucgdDgsw/3ZIOq+IVwXya+Axqst3sHz5km8s94XvBcgjzHF1jyeGiN9UEBSN
R+ecT8rF5ogC6OsBpgTMHYASpcuGimLsupz1HE7bz/2o95hIdb6NaV4Ni2FYy/VoiwIBEQ==
[end]
You should end up with this one in your database after the delete and sync
described above.
--
Cheers,
Derek
| 
