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

[subharo at hushmail.com]

Hello Tamme,

On Sun, 08 Sep 2013 11:52:58 -0400 "Tamme Schichler" 
<tammeschichler at googlemail.com> wrote:
>>  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.
>
>and precisely that is the problem. As people with technical 
>background
>deleting a lockfile is trivial for us, but that won't be true for 
>most
>users, especially if there's a "friendly" error message that 
>doesn't
>contain the path of the problematic file.

I'd propose that each IM client only opens the config files they 
need *very* briefly (like, for under 1 second), *only* when they 
need to (like when initiating an OTR conversation, validating OTR 
fingerprints, and loading all known fingerprints (so they can be 
all shown and managed from the Options/Preferences).  

So lockfiles exist only for those <1 second times.  Only a crash 
during those <1 second times could cause a stale lockfile to be 
left behind.  That is to say, IM client shouldn't open the config 
files for reading/writing upon initial execution, leaving the file 
handles open the whole run time, then closing then only when the 
program terminates.  In other words, no IM client should "Bogart" 
the config files.  BTW: Putting a "refresh" button on the OTR 
fingerprint management interface in the IM client's 
Options/Preferences can take a fresh <1 second look at the config 
files (just like when you press the Refresh button in your web 
browser).

Let's remember that most people would have only say, dozens of 
contacts, so we're not processing alot of data here.  We don't have 
to get all that fancy, IMHO.  And most people would only run *one* 
IM at a time, so our mechanism of concurrency (to allow multiple IM 
clients at once to use the config files simultaneously) can be 
slightly flaky and imperfect (since it'll usually never even 
matter).  

My point is this: people who run multiple IM clients at once (and 
really push the system hard, to possibly create crashes that lead 
to stale lockfiles) are also the kinds of geeks who are probably 
smart enough to delete stale lockfiles.

>Speaking from experience, you can't assume that a non-technical 
>end user
>will reliably find their configuration directory or be able to
>understand the problem from a short error message without further
>instructions.

I agree.  Having said that, hopefully most people are smart enough 
now to Google/DuckDuckGo for their error messages now, and they'd 
find the advice to look for and delete stale lockfiles.

Error messages could specifically say to delete any stale lockfiles 
in (config directory here) if no other IM client is running (and 
thereby truly deserves to be locking the config files).

>A possible fix would be to add a timeout to the specification 
>after
>which the lock can be automatically removed, or to require 
>programs to
>implement an interactive recovery. 

Hmm, I like this idea, but I don't see how to keep it simple 
enough.  This sounds complicated.

>I think a loopback daemon that listens for TCP on a specific port 
>would
>be much simpler. 

But wouldn't firewalling software want to block this by default?  I 
think the average user is too unsophisticated to adjust their 
software firewall settings.

>As almost all applications that use OTR would be
>networked, a TCP connection would require no additional 
>dependencies,
>unlike XML or JSON which are not included in every standard 
>library.

Good point.

>It would also be trivial to enforce compatibility: If the daemon 
>accepts
>only (and validates) e.g. UTF-8 and a specific binary command and 
>reply
>format, it becomes impossible for a program to work by itself but 
>fail
>when another one is in use.

>The server would only need a few atomic commands, e.g.: 
>Add/Update, Mark
>as Revoked, Get Info and List Signatures. There would have to be a
>reliable specification about how to associate specific accounts 
>with the
>signatures (and possibly how to attach additional meta-data. I 
>think the
>client applications should store non-portable data themselves,
>separately, though.), but that is the same issue as with files.
>All additional debug and management commands (Remove...) and the
>underlying representation could be abstracted away from the 
>consumer or
>optional.

That part sounds great.

>The only problem I see with this is that starting the daemon or 
>service
>wouldn't be platform agnostic, but the configuration files' 
>location
>wouldn't be either, so it probably would be a simple branch in 
>either
>case, in the client.

Agreed.  This gets ugly as each OS has different service 
management!  Even Ubuntu's service framework is different from many 
other linux distros.