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

[Timothy Brownawell]

On Sun, 2008-10-19 at 15:22 -0700, Robert White wrote:
> -----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. 

Monotone internally identifies keys by name, rather than ID, and
nobody's ever gotten around to fixing this. This causes various problems
if databases with the colliding keys every come in contact with
eachother.

>  This is hugely
> unworkable with one default keystore. This was not previously a problem.

There is another use, where people will often want to use the same key
in multiple databases that do talk to eachother. If a key is local to a
database, it's more common that they'll generate a second key with the
same name and have problems when syncing both databases to the same
place. This still happens occasionally with people who use multiple
machines, but it's less common now.

> 1) It presumes that any given login ID and key id uniquely identifies
> a database.

Monotone assumes that there is only ever one key anywhere with a given
name.

> 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.

It also makes it safer to send databases to other people, such as for
debugging. IIRC this was the main motivation behind having a separate
keystore, people would forget to drop their private key before posting
the db somewhere for debugging. Sure, the keys are stored encrypted, but
they still shouldn't be distributed like that.

> 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

What prevents using the same key? I could see wanting different keys if
you had to use them from someone else's machine, but would something
like <name>+<machine owner>@<domain>, say address@hidden, not
work?

Also, what happens when one employer merges with / is bought out by
another and they decide to combine their codebases? Colliding keys could
cause unexpected problems in that case.

> 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).

That can be a one-time operation. Or, there's the possibility of using
different keys with different names on the different machines.

> 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.

No, the default should stay as it is to prevent people accidentally
exposing their keys. We probably also don't want to encourage uses that
break monotone's basic assumptions, it'd be much better to get around to
fixing the assumptions instead...

> 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.

...no backup copies from immediately before 'db migrate'?