monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL


From: Thomas Keller
Subject: Re: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Date: Mon, 20 Oct 2008 10:05:11 +0200
User-agent: Thunderbird 2.0.0.17 (X11/20080922)

Hi Robert!

Sorry to read that you've lost your keys during upgrade - no chance to
have a backup laying around somewhere?

You wrote:
> 1) It presumes that any given login ID and key id uniquely identifies
> a database.  To whit
> 
> mtn --db Employer1.db db migrate
> mtn --db Employer2.db db migrate
> 
> (== no more private key address@hidden from database Employer1.db)

What would be interesting here is if mtn has warned you between the
first and the second `db migrate` that there is already a private key in
~/.monotone/keys with the name "address@hidden" or if it blindly
overwrote the "extracted" one from the first migration. If the latter is
the case, I suspect this is a bug which should just be fixed.

> 2) the mechanisms don't check they keystores for parity before doing
> dangerous operations.
> 
> mtn --db Employer3.db dropkey address@hidden
> 
> Gee, the private key in .monotone/keys/address@hidden wasn't the peer
> of the public key in Employer3.db, too bad, so sad.

I'd consider this a bug as well. Apparently the signature of the public
key in database is not compared with the one of the private key in
keystore. But I'd have to have a look at the code before I can say this
for sure.

While I'd generally support the proposals from other people saying that
some kind of <username>+<contractor> syntax should be used until mtn
finally sorted the "keys are solely identified by their ID" issue out,
there are other ways handling this issues in existing projects (this
should then also avoid name clashes if revisions of two different
projects suddenly arrive in one database and have been signed by equally
named, but distinct keys before).

So, another intermediate solution could be, f.e. to add a couple of
~/.monotone/keys/<projectname> directories and place the
address@hidden's in these subdirectories.

Then, for each project workspace define your own _MTN/monotonerc and use
the get_default_command_options() hook to prefix every command you're
triggering there with a --keydir ~/.monotone/keys/<projectname>. You
could also go the old unix route and just add a shell alias to separate
those different keys / projects.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]