Re: [Monotone-devel] Rosterify and certificate keys

[Nathaniel Smith]

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!

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?

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.

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

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould