[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Rosterify and certificate keys
From: |
hendrik |
Subject: |
Re: [Monotone-devel] Rosterify and certificate keys |
Date: |
Wed, 12 Apr 2006 07:48:42 -0400 |
User-agent: |
Mutt/1.5.9i |
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
- Re: [Monotone-devel] Re: Rosterify and certificate keys, (continued)
- Re: [Monotone-devel] Re: Rosterify and certificate keys, Richard Levitte - VMS Whacker, 2006/04/11
- Re: [Monotone-devel] Re: Rosterify and certificate keys, Timothy Brownawell, 2006/04/11
- Re: [Monotone-devel] Re: Rosterify and certificate keys, Wim Oudshoorn, 2006/04/12
- Re: [Monotone-devel] Re: Rosterify and certificate keys, Nathaniel Smith, 2006/04/12
- Re: [Monotone-devel] Re: Rosterify and certificate keys, Derek Scherger, 2006/04/12
Re: [Monotone-devel] Rosterify and certificate keys, Daniel Carosone, 2006/04/10
[Monotone-devel] Re: Rosterify and certificate keys, Tom Koelman, 2006/04/11
Re: [Monotone-devel] Rosterify and certificate keys, Nathaniel Smith, 2006/04/12
- Re: [Monotone-devel] Rosterify and certificate keys,
hendrik <=