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

[Robert White]

Ethan Blanton wrote:

>
>That said, the conflation of email address and key ID is an
>unfortunate early design decision in monotone which pretty much
>everyone now understands was not ideal. Keys in databases are not
>ideal for other reasons (databases should not be sensitive, as it is
>reasonable to share them, primarily). Unfortunately, changing key IDs
>to something more sensible (such as hashes, as used in most crypto
>systems) will require a re-issuance of all certs, which is a pretty
>big deal. Because of this, it has been put off until other
>backwards-incompatible changes which are known to be necessary can
>also be implemented, so that there needs to be only one more flag day
>in the foreseeable future.

In my humble opinion I don't find the use of email address to key id to be
an issue. It makes reasonable sense and it is memorable and meaningful
to all the users.

The problem is that the databases (plural) now have this annoying desire
to automagically share this single external entity (the contents of
.monotone/keys)
in a destructive way.

One of the major selling points of monotone _was_ that the database
file was
all you needed to have a consistent store, and you could have as many as
you needed to get what you done.

Now I can be working on one database and accidentally ruin another because
a genkey or dropkey will act on this default store unless you remember
to redirect it.

So now instead of having one consistent store I have to synchronize
use of a database
file and a directory.

Claiming it as a security action is a red herring. The key files are
encrypted anyway
and physical access to the database is just as likely-or-unlikely as
physical access
to the keydir.

At the least we should have, on a database-instance by database-instance,
the choice of whether we want this common pollution area known a keydir.

Pardon me for bing somewhat annoyed, but I managed to lose several
important
keys in the upgrade because of this common keydir thing that was less than
prominently warned about in the documentation etc.

So anyway, I don't mind using the email addresses.  And an astute observer
will notice that you don't _really_ need to use an email address when
you genkey,
so that's not a weakness of design, just common use.

So the reuse of email address as key id has been quite useful to me up
till the keydir disaster.

Its the arbitrary conflation, the lack of checking on the destruction
of the keydir contents, and
the sudden requirement of parallel data management outside the
datastore that I find
offensive to common sense.

.monotone/keys

a _bad_ default.

maybe a good _option_, maybe not.

Perhaps just my opinion, but the real world application I have was
just fine before
the advent of this "feature" and now monotone is _fantastically_ less
useful to me.

Blaming the key id selection, which is essentially unenforced (I don't
see it checking
the email etc) as a bad design decision is far less true nor useful
than understanding
that adding an external dependency between otherwise un-conflated
databases _is_
a design flaw, added at a late stage, that just makes things suck once
you get to
non-trivial use cases.