Sorry for not getting you a response sooner.
On Thu, Dec 01, 2005 at 04:48:30PM -0800, Howard Spindel wrote:
> I have two monotone databases.
>
> I performed "monotone db migrate" successfully on the first one, and
> a key was stored in the new Windows location.
>
> I then attempted "monotone db migrate" on the second database and got
> the following error:
>
> monotone: error: Cannot store key 'address@hidden'; a different key
> by that name exists.
>
> Apparently I had different keys in the two databases and that worked
> because the key traveled with the database. Now that it's moved to a
> fixed location it collides.
Yeah. This was always a problem waiting to happen, unfortunately, as
soon as the two keys got mixed up (say if you used the same server to
post changes to both projects). One of the good points of the fixed
location is that it makes it much harder to accidentally get into this
situation in the first place...
> What is the recommended procedure to fix this?
Unfortunately, there is no great solution to this :-/. About all you
can do is throw out one of the keys, and re-issue your existing certs
with the key you keep. (The branch certs are the important ones,
though you might want to re-issue the other ones too.) And then tell
all your friends and your server admin to all throw out your old key,
and maybe delete your old (pre-reissue) certs. There's no way to
rename a key, or have multiple keys with the same name.
Key management in general is quite an annoying problem, and we've been
deferring it until now in order to get basic VCS stuff in. I'm sort
of amazed people haven't run into such issues more often, actually,
but, it's seemed to be very rare in practice, so it hasn't come to the
top of the priority list... which, of course, is no excuse. Apologies
that we don't have anything better.
There are a few different options that might make sense, in an ideal
world. The tricky part is essentially a UI question -- how to make
sure that people's practices when referring to and reasoning about
keys, actually work. In particular, it seems important to be able to
tell someone "oh, yeah, I know address@hidden, you can trust her
code", and know that when they go on their computer and say
"address@hidden", that will end up referring to the same key that
_your_ computer has as being labeled "address@hidden".
There's been some discussion of this before; there are at least two
possibilities I know of -- some sort of "referential contagion"
scheme, where people you talk to get infected with your name<->object
mappings, and some sort of scheme where we have a quasi-centralized
per-project trust database people use, and this also holds the
name<->object mappings. Both are discussed somewhat here:
http://article.gmane.org/gmane.comp.version-control.monotone.devel/5245
Hope this helps,
-- Nathaniel
--
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."
_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel