[OTR-users] Pretty-please standardize OTR signature storage, per OS.

[subharo at hushmail.com]

Hello,

Thanks for the feedback an ideas!  Glad to hear there is some 
interest.  :D

On Fri, 06 Sep 2013 14:25:35 -0400 "Daniel Kahn Gillmor" 
<dkg at fifthhorseman.net> wrote:

>I'm not convinced that just outlining a location in the filesystem 
>for
>the data is sufficient, though, because of issues with concurrent
>updates; e.g. what if Alice's OTR-enabled tool X tries to make a 
>note of
>Bob's fingerprint at the same time as OTR-enabled tool Y tries to 
>make a
>note of Charlie's fingerprint?

Agreed.

>use of an agent-driven approach (e.g. a dbus query or talk to a 
>local
>daemon bound to the loopback or something) could serialize and
>centralize access without causing more trouble.  Related to 
>earlier
>discussions about looking up long-term OTR identity keys in the 
>OpenPGP
>keyserver network, it seems plausible that you could use a 
>modified
>monkeysphere validation agent for this purpose; bummed i don't 
>have time
>to work on it further at the moment, but if folks want to push in 
>that
>direction, i'd be happy to kibbitz.

I was hoping for something simpler and more elegant than this.  How 
about simple file locks?  If some flat config file (say, with OTR 
fingerprints inside, with some nice XML or JSON markups or some 
such) is in use by some IM client, that IM client "touches" (ie. 
creates a file of size zero) a lockfile in the config folder 
(having the same filename, but ending with ".lock").  Then one IM 
client won't *write* to a config file if it sees that a lockfile 
already exists (because some other IM client is already locking 
it).  And it can tell the user to "try again later" if so (after 
checking itself a few more times, every few seconds).

This way, more than one IM client can *read* the config files at 
once, but each IM client can only *write* to the files one at a 
time.  And a given IM client should *only* create the .lock files 
for just as long as they're needed to make an update to the file, 
like say < 1 second (just for *writing*).  OTR fingerprints are 
probably added by users rather infrequently (no thousands of 
commits per second here!), so this simple method should suffice for 
about 99.999% of all users, IMHO.

To make it even more "atomic", the new file is created with a 
random suffix (a UUID), and then once the lockfile is in place, the 
new file is "moved" overtop the old file, upon committing, then the 
lockfile is removed.  In the unlikely event that an IM client 
crashes in the middle of that 1 or 2 seconds, then they'll have to 
manually have to delete the lock file and pick which file is the 
one they want, the new one (with the random suffix) or the original 
one.  And surely one of the two files is in a coherent, ungarbled 
state, no matter at which instant a crash occurred.  This is not an 
uncommon way of "cheaply" implementing concurrency, as I'm sure 
we've all had to delete a stale lockfile from time to time.

Sure, there are many sophisticated flatfile DB's one could use that 
enforce concurrency (like say SQlite, or Python's Durus, which uses 
nosql), but then you introduce more package dependencies, and you 
make it less OS-agnostic.  I think going the route of using some DB 
will push a solution about 10 times farther away.

What I'm advocating here (via simple lockfiles, and almost-atomic 
commits) is a decent, *OS-agnostic* solution, which is quite 
elegant, and simple.