Re: [Monotone-devel] Remote public key hash unknown

[Timothy Brownawell]

On Sun, 2007-11-04 at 18:06 +0000, Ben Hood wrote:
> Hi,
> 
> I recently upgraded my computer and I doing so I forgot to backup the
> original keyfile that I was using to push stuff to our mtn server.
> 
> I regenerated it and found out that the pubkey hash is the same as the
> old one I mailed to the who installed my key on the server.

That can't be right...

Oh. If you're in a workspace or give the --db option, monotone will
display the version in the db. If you're not, it will display the
version in the keystore.

This is a Very Bad Thing, it should E() if there are keystore and db
versions that don't match.

You new key is completely different from your old key. Monotone saying
that the pubkey hash didn't change is a bug (triggered by having two
pubkeys with the same name).

> So I thought I'd be good to go, but I ran to a warning whilst
> committing and an error during the sync:
> 
> $ mtn commit -m 'xxx'
> mtn: beginning commit on branch 'com.rabbitmq.erlang-client'
> enter passphrase for key ID address@hidden:
> mtn: committed revision ddfb25fd0a78c1d0853b554c8bca06ce8db8a73e
> mtn: warning: ignoring bad signature by 'address@hidden' on
> 'address@hidden:Y29tLnJhYmJpdG1xLmVybGFuZy1jbGllbnQ=]'
> mtn: warning: ignoring bad signature by 'address@hidden' on
> 'address@hidden:Y29tLnJhYmJpdG1xLmVybGFuZy1jbGllbnQ=]'
> 
> 
> $ mtn sync
> mtn: connecting to dev.rabbitmq.com
> mtn: finding items to synchronize:
> mtn: certificates | keys | revisions
> mtn:          417 |    7 |       139
> mtn: warning: protocol error while processing peer dev.rabbitmq.com:
> 'received network error: remote public key hash
> '801dc474ae1d8964b734383c38de795bcedfbca4' is unknown'
> mtn: bytes in | bytes out | revs in
> mtn:      104 |       341 |       0
> mtn: error: processing failure while talking to peer dev.rabbitmq.com,
> disconnecting
> 
> Have I done something wrong here?

If you lose your private key, generating a new key with the same name
will break things. If you really really need to have your new key have
the same name, it will be a horrible pain and require cooperation from
everyone who pulled anything signed by your old key. Otherwise generate
a new key with a new name, and use that instead (and drop and re-commit
what you committed with the broken version of your key).

> The other potentially influencing factor is that I downloaded the 0.37
> version after I did the upgrade, whereas previously I was using 0.36.
> I'm using OSX 10.5.

That shouldn't have any effect on this.

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net