Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0

[Ludovic Brenta]

Timothy Brownawell <address@hidden> writes:
> For certs signed by key address@hidden (abcd...):
>  * If there is only one key with that name, there are no
>    user-visible effects.
>  * If there is also a key address@hidden (1234...):
>     * If the new-version peer has both keys, there is no
>       user-visible effect when it receives certs.
>     * If the old-version peer only has 1234... and the
>       new-version peer doesn't have abcd..., then the new-version peer
>       will drop the incoming certs (because the old peer can't send it
>       the correct key, so it can't correctly identify the key hash to
>       attach the certs to) and print a warning.

Fair enough (1).

>     * When the old-version peer receives certs signed by the key it
>       doesn't have, the new-version peer will try to send that key
>       and the old-version peer will drop the connection with "received
>       duplicate key".

Fair enough (2).

> Hmm. If you migrate a database containing key address@hidden (1234...) and
> certs signed by key address@hidden (abcd...), the upgrade logic will attach
> them to that (wrong) key because it assumes your db is consistent. So we
> need a command that will try to reassign any invalid certs to the
> correct key, and maybe optionally delete them if it doesn't have that
> key (so you'll be able to get a good copy, with the key, during your
> next pull). We probably also want to drop certs with bad signatures (ie,
> attached to the wrong key) during netsync, so they don't spread.

But a database that needs upgrading is necessarily <= 0.44 and therefore
cannot possibly contain two keys with the sane name, can it?  And per
(2) it cannot contain certs signed by the key it doesn't have, can it?
So your scenario cannot happen, can it?

So all is well... ?

-- 
Ludovic Brenta.