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

[Timothy Brownawell]

On Sat, 2009-08-29 at 17:25 +0200, Ludovic Brenta wrote:
> 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... ?

What can happen is
 * I have a key address@hidden, and produce some certs with it.
 * I lose my private key.
 * I either still have my db, or pull a fresh one.
 * I generate a new private key, without specifying a db (so
   monotone doesn't know about the existing key and doesn't
   complain).
 * I produce more certs, using my new key.
 * My db now has 1 key address@hidden (the old one) but has certs
   signed by two separate keys with that name.
 * When I eventually upgrade to 0.45, I have bad certs that
   need fixing. Anyone else with 0.44 or earlier, who I synced
   with before upgrading, will also have bad certs.