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

[Robert White]

Timothy Brownawell wrote:

>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.
>  
>
Sure, but wrong anyway since the now the dissimilar keys
don't get caught in the point of use, but now get communicated
to the third party. Not a big loss, but not exactly a win either.
This is a cosmetic shift that seems a little "meh" to me.

>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.
>  
>
Weak passphrases and sending physical databases is an exposure,
agreed. Forcing me to transmit .monotone/keys around is just as bad,
though a lot less likely to happen by accident.

But moving on...

>  
>
>>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?
>  
>
The "surrender or destroy" clauses of most contract would make
using the same key "problematic" since you agree to surrender
or destroy "it" separately at the end of both contracts that don't
necessarily end at the same time, and for which you are constrained
from conflating so giving Employer1 the key would compromise
Employer2 (etc).

As for bob+foocorp; people who expect to be able to use the email
addresses aren't necessarily going to be wanting to see/create/use
+foocorp, nor remove same, particularly since now you are leaking
"foocorp" into a data stream where it may not be welcome (sub of
a sub contractor etc).

There is no reason that the keys have to be anything legit, since the
genkey stuff doesn't do any external validation, but suggesting that
adding non-information is a solution to collision of valid information
is a little bogus IMHO.

>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.
>  
>
Yep, that sucks, but at the worst, if the merger happened at the project
database level, you could pick one and move on since the records would
_still_ all show "address@hidden" for all entries.  having
address@hidden and address@hidden would
be more confusing than just retiring one of the keys from common use
and having the thing end up otherwise looking correct for all usage.

>  
>
>>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.
>  
>
That _can_ be a one time operation, but in my case it is a twice a day
operation.  Lucky me.  So I carried the .monotone/keys entry home
on an encrypted drive. But now it collides between the work I had to
create at that place, and my general GPL-ish work. Yea I could start
using different system logins etc. I could also pretend to teleport or
simply wish away the firewall rules I cannot change at work...

Yes I _can_  repeatedly use --keydir, but so much less convenient
than when it just worked by pointing to the correct database when
establishing the workspaces.  Now for every --db I have to supply
a matching --keydir argument etc.

Ever so less reliable and more mistake prone.

>  
>
>>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...
>  
>
Why the default should be to protect the encrypted keys at the cost
of potentially conflating the entire set of active databases is beyond
me. But even so, the _default_ should be configured into the database
on a per-instance case.

For instance "genkey" could create .monotone/keys/keyid by default
but all the key operations should check for "select * from privatekey
where keyid=indicated" before checking for .monotone/keys/indicated.
Then there would be a import/export operation for having the key
in or not-in the database as desired.  Meanwhile "migrate" wouldn't
write to .monotone/keys/keyid ever, nor would dropkey delete a secret
key file _EVER_ since if you _ARE_ using the same key in multiple
databases, that would _ALWAYS_ be wrong.  This would lead to one code path
that would allow for the keys to remain wherever they already were,
and individual users would be able to decide whether they wanted
their keys conflated in one directory or stored within their databases.

Problems solved...

>  
>
>>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'?
>  
>
My situation was neither hopeless nor unrecoverable but it took me a _hell_
of a while to figure out what essentially undocumented change made the old
work while the new didn't.  In particular, since it wasn't happening all
at once
(the various migrations were "as needed" and since after each operation the
new database tested good, it was misleading. There was non-trivial time
between the migrations and each project continued to move forward.

migrate A
use A for two weeks
migrate B
use B for a week
migrate C
use C
Discover that A no longer works. SURPRISE!

And using the just-pre-migrate backups of A and B not a true option
since that
discards the intermediate work, etc.

It's a freaking land mine.