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. _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
