[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:
>I think a loopback daemon that listens for TCP on a specific port
>would
>be much simpler. 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.

After thinking through your idea, I think I've found a potential 
problem that should be pondered.  In Windows, your loopback daemon 
would work fine, because Windows is not truly Multi-User (in the 
sense that *you can't multiple human users logging at the same 
time,* with separate, independent "Sessions").  In Unix, it's 
different.  Unix is truly Multi-User in the sense that you can have 
one human at the physical keyboard, video and mouse, then other 
humans SSH'ing in remotely (or better yet, starting remote, secure 
X sessions using X2go).  

Unix user Alice running your loopback daemon could have her keys 
read, modified, or deleted by Unix User Bob, who has SSH'ed/X2go'd 
into that same machine.  An example scenario: University students 
playing pranks on each other in Unix computer labs with NIS+/NFS 
network accounts giving them access on all the other UNIX machines.

Your proposition has no security mechanism protecting that loopback 
daemon listening on 127.0.0.1, except the absence of other human 
users (legitimate or not) being logged in (who also have access to 
the loopback network interface).

I think your idea needs a security mechanism, like say, a master 
password, before the OTR signatures can be accessed.  Kind of like 
how the Gnome Keyring, or KDE Wallet wants you to set a master 
password before you can open said Keyring/Wallet.  Would you agree? 
 To me, yet one more password doesn't really matter to me, as I 
just randomly generate it with Lastpass, and save it in Lastpass.  
And I think all IM clients already have their own means to save 
passwords (for each of the IM accounts) so one wouldn't have to 
enter passwords each time one launches the IM client.  I think an 
IM client could similarly remember such a master password for 
future use.

Do you, or perhaps someone else, know if there is an easy way to 
implement some such adequate, yet simple, security mechanism?  
There's some convenient Python library already existing to do this. 
 I'm not enough of a python geek to recommend one, especially as 
standing above all other competing solutions.  Has anyone explored 
this problem domain in the Python world?  

Hopefully a simple solution exists, which still makes your idea 
attractive (over my original proposition, which just used plain old 
filesystem operations, simply relying on filesystem permissions as 
a convenient security mechanism).