On Tue, Apr 11, 2006 at 11:48:59PM -0700, Nathaniel Smith wrote: > On Mon, Apr 10, 2006 at 05:25:56PM +0200, Tom Koelman wrote: > > I just rosterified a database. On inspecting the contents of the new > > database I found out that all certificates had been reissued with my > > own e-mail-adress. This would be an issue for a trust model based on > > who handed out what certificate. Is there some way in which I can make > > the certificates keep their original key? > > > > Another thing I noticed is that, understandably, all revision hashes > > have changed. This has the unfortunate side effect that propage > > Changelog entries make no sense anymore, as they contain two revision > > hashes from the old database. Also, some of my handwritten changelog > > entries have the same problem. Is there some way in which I can > > replace these old revision hashes with their new counterparts? > > Right. I definitely should have made a bigger point of this in the > release notes. I'm sorry; didn't think it through. I've just > committed another paragraph to UPGRADE on mainline describing this, > and updated the version on the website as well. > > The rev ids changing is similar; it's definitely disruptive, and it's > certainly intended to work to leave revids in random places! (We > have some scattered in monotone's source code, for that matter.) I > was just hoping we could get through one last rebuild without adding a > bunch of permanent machinery to deal with it. Should have checked > with the list first!
Without a method to find all revision id's anywhere, we'd need an index relating old and new revision IDs. Would is suffice to just make a text file that a user can search, or do we have to automate all this? Unfortunately, that would be yet more complexity. > > There are only two changes of this order of magnitude that we know are > coming in the future. The first is the clean up of certs and trust > generally. That won't affect revids. One of the changes planned is > to add an "author" field to _all_ certs, so certs become > "such-and-such key asserts that so-and-so said ...". This should help > with a lot of these problems, I think? This is good. > > The other is the replacement of SHA1 by whatever the crypto community > (eventually) settles on as better. This does affect revids, > obviously, but since it isn't happening in the immediate future > anyway, the thought was that there will be plenty of time to figure > out how to minimize the disruption when it does finally happen. That would change the revision IDs again, woudn't it? Or we could recognise both sets of revision IDs -- the old ones for old revisions, the new ones for new ones. Perhaps some syntactic marker could distinguish them. > > Again, apologies; certainly if anyone wants to work on any of the > ideas discussed in this thread to reduce the impact of this, we'd be > interested in integrating those patches. > > -- Nathaniel -- hendrik _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
