Re: [Monotone-devel] Re: Server up

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Wed, 04 Aug 2004 21:46:22 +0100, Bruce Stephens 
<address@hidden> said:

monotone> Richard Levitte - VMS Whacker <address@hidden> writes:
monotone> 
monotone> [...]
monotone> 
monotone> > As far as I can see, there's no easy way to remove a key, so I had
monotone> > to start over (remove the database after making sure I got diffs for
monotone> > all things that only exist there, init a new database, ...  you got
monotone> > the drift :-)).  I would very much like to see some commands to
monotone> > manage keys with added, would that be possible?  I'll see if I can
monotone> > think of some ideas to make that safe and elegant at the same time.
monotone> 
monotone> By the looks of schema.sql, there's an unsafe and inelegant way:
monotone> 
monotone> monotone debug "delete from public_keys where id='address@hidden'"
monotone> monotone debug "delete from private_keys where id='address@hidden'"
monotone> 
monotone> You could even check that the keys weren't used first:
monotone> 
monotone> monotone debug "select hash from manifest_certs where 
keypair='address@hidden'"
monotone> 
monotone> However, I'm not sure I'd be brave enough actually to try
monotone> it.

Hmm, I'm gonna dare it.  I made another mistake (hey, that's a way to
learn, right?  :-)), and created another project-specific local
database (let's call it foo.db), and used the same key identity there
as I did in my local monotone.db.  Now that I want to push the
contents of "foo.db" to the same server to which I push my local
monotone.db, I realised that there will be an identity conflict.

What I plan to do is to rename "address@hidden" to
"address@hidden everywhere in "foo.db".  Hopefully, that
should pose no problems.

In all honesty, I'm a little dubious about having the keys internally
identified by this textual identity instead of the key+id hash.  From
a security point of view, it's the key that's important, not the
identifier string attached to it.  Furthermore, there's absolutely no
reason why one identity couldn't have more than one key pair.  From an
implementation point of view, I can see that it might be a little more
cumbersome (sp?) in some cases, but not much.  It could be solved by
requiring unique ids in the private key table and only there.

As far as I can see, having the keys be identified by hash rather than
key identity would only require the following:

 - have id in manifest_certs be the key+id hash (i.e. the
   corresponding 'hash' from public_keys) rather than the id.
 - have id in file_certs be the key+id hash rather than the id.
 - change whatever code that depends on the above two changes.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/