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

Tamme Schichler tammeschichler at googlemail.com
Sun Sep 8 16:44:05 EDT 2013


Am 08.09.2013 19:07, schrieb 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).

You're right, it should be possible for almost everyone to solve it 
eventually. I would prefer a system without a manual-recovery failure 
state, but I agree that it wouldn't be hit often enough to be a 
significant problem.

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

I can't speak for Unix, but on Windows an open port that only listens 
for connections from localhost is always allowed and doesn't show any 
warning to the user when it's created for the first time, afaik. Most 
3rd party firewalls should behave the same way, if they warn about it 
there should be an option to whitelist the program directly.

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

I think a simple executable in user-mode would be enough, running a 
loopback service and changing %appdata% doesn't require elevated 
privileges. On my system gpg-agent is started on demand this way, if one 
already runs the new instance exits after verifying that the running one 
is active. (The port number is taken from a file, or maybe written to it 
after the agent starts. It may have to look for a free one.)

On Unix systems it seems to use domain/IPC sockets, which are unaffected 
by firewalls and controlled by file permissions instead. I imagine the 
implementation is platform-agnostic after starting the agent process and 
getting streams connected to the TCP/IPC socket.



More information about the OTR-users mailing list