On 07/03/2007, at 3:04 PM, William Uther wrote:
> A developer here was working at a remote site. He took a copy of
> the db but not a copy of his key. He generated himself a new key
> (using the same key id as his normal key), and committed using it. He
> got some error (now lost in the mists of time). Another dev with a
> laptop got a copy of the changes using diff/patch and committed them
> using his correct key.
>
> Unfortunately, the db with the bad rev was sync'd into the cloud of
> db's and now everyone is getting this message:
>
> mtn: warning: ignoring bad signature by
> 'address@hidden' on
> 'address@hidden:YXUuY29tLm5pY3RhLmRn
> Yw==]'
Actually, I guess another option would be to specifically update to
that rev and then commit a correctly signed child rev. That would
mean that that rev would no longer be a leaf and mtn might stop
complaining (right?).
Pro:
It would mean that we don't have to kill the rev everywhere in the
cloud (which can be tricky - those dbs multiply like rabbits).
Cons:
It would have the problem that the rev had already been re-committed
somewhere else and so we'd get conflicts (not too hard to resolve
them though).
Similar to the re-sign everything concept, but easier to do if you're
not a mtn guru.
On a related note, I don't really understand why mtn accepts badly
signed revs/certs into the db at all. Shouldn't it warn and drop the
certs/revs? There is already lots of checking in mtn, I'm surprised
this isn't caught. I can imagine how you could get sets of dbs in a
cloud that disagree about who the real Spartacus is, but would have
thought you'd get the error on syncing, not every operation that
touches a leaf afterwards.