On Sun, Nov 04, 2007 at 07:55:10PM -0600, Timothy Brownawell wrote: > Could we also handle this by making process_data_command error() on > data_exists for a key item? I believe all keys are sent before any certs > are sent, so this should block any key collision errors from propagating > over netsync.
It already does error out if you try to put two keys with the same name into the same db. I'm not quite sure how the developer in question managed to achieve this -- maybe Ethan will explain in more detail. It sounds like he once upon a time generated a key, issued some certs, and then erased that key and used another key for all actual work -- and now, much later, somehow managed to accidentally release one of those old certs into the wild. I don't know if the db that the bad cert came from even contained the offending key or not. Does netsync really send keys first before certs? I don't remember that. (In general we don't consider it an error to have a cert without a key, so it might not be being handled the same way as say files-before-revs-before-certs.) Does netsync send certs that it doesn't have a key for? Those should probably just be ignored, but perhaps they aren't... (For that matter, is there any reason to ever send along a cert with a broken signature? Of course, we don't cache signature checks in the db ATM and checking cert signatures is expensive, sigh.) -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
