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

[subharo at hushmail.com]

On Sun, 08 Sep 2013 16:44:12 -0400 "Tamme Schichler" 
<tammeschichler at googlemail.com> wrote:
>Am 08.09.2013 19:07, schrieb subharo at hushmail.com:
>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.

I can speak for Ubuntu, and I'm pretty sure all other distros 
similarly follow suit (and somebody please correct me if I'm 
wrong): all ports are open by default (and very light firewalling 
is in place: only when destinations potentially have an "icmp-port-
unreachable" is a packet rejected).  

You can check this for yourself on a linux system with the command 
"sudo /sbin/iptables -L"

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

OK, your idea has lots of merit because it's cleaner sounding, and 
you've almost totally convinced me.  But let's take it a little 
farther.

This "simple executable" you speak of: am I right that it would be 
platform-specific, compiled into machine-code for all common OS's 
(Windows Vista, 7, 8, OSX, Linux), and architectures (i386, AMD64, 
ARMv7, and possibly ARMv6 for Linux)?  Now some simplicity is being 
lost, would you agree?

Also: what language would you have it be written in, such that one 
lone executable file has no other dependencies that don't already 
exist in the available libraries in stock OS installs (where it'll 
be used).

Also: which of the following two routes would you prefer, to 
distributing this executable?

1) Bundled into each IM client. Hopefully it won't too be hard to 
convince all existing IM projects to bundle this into their 
respective installers and software packages (even though it might 
not be written in the language they like to use for their project).

2) It's a separate software package itself (which would be 
"depended upon" as necessary)?  In other words, it sounds like this 
little executable is possibly sophisticated enough to justify it's 
own name, own website, own downloads page (per OS version and 
relevant architectures), etc.