monotone-devel
[Top][All Lists]
Advanced

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

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


From: Robert White
Subject: [Monotone-devel] WARNING: ~/.monotone/keys CONSIDERED HARMFUL
Date: Sun, 19 Oct 2008 15:22:58 -0700
User-agent: Mozilla Thunderbird 1.0.7 (X11/20050923)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy all,

I don't know who decided that .monotone/keys was a good idea but it is
a DISASTER for me.

For various reasons It is desirable to use the same real world
identity, q.v. address@hidden, in several different databases with
different keys behind them for each database.  This is hugely
unworkable with one default keystore. This was not previously a problem.

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)

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.

3) It makes walking around with a database on your flash drive much
more annoying in every way.

If you don't believe in these use cases, consider contractors who may
need to keep work separate for different employers but will want to
use their one business email address for all their business; or
consider the need to have two or more development stations that _can_
_not_ reach each other over a network, so sneaker-netting a secondary
store would be required.  (and so on).

I understand the utility of being _able_ to have an external key
store, but it should by no means be the default that the database
_doesn't_ have the private key inside it. Or at the least the
_ability_ to have the private key inside it in its own table.

Anything that presumes just one database or allows two databases on
the same machine owned by the same user to cross-pollinate or disrupt
each other is a misfeature.

I recently updated from a much older version and I now have two
databases that are essentially screwed.

Thank you for your consideration.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFI+7NBMLJWEiVQHi0RAlzJAKC0Ytcdc3ckBDlc+dwjPw9im4/XLgCfeK55
gbT+KhX7Xbb/UytSNDhqsh4=
=uy6a
-----END PGP SIGNATURE-----





reply via email to

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