On Sat, 2009-08-29 at 17:25 +0200, Ludovic Brenta wrote: > Timothy Brownawell <[email protected]> writes: > > For certs signed by key [email protected] (abcd...): > > * If there is only one key with that name, there are no > > user-visible effects. > > * If there is also a key [email protected] (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 [email protected] (1234...) and > > certs signed by key [email protected] (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 [email protected], 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 [email protected] (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. _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
