Re: [Monotone-devel] Rosterify and certificate keys

[hendrik]

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