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

[Tamme Schichler]

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

Yes, as executables (and system calls) aren't that portable it would be 
necessary do create packages for different platforms. The part of the 
program that listens for new connections would need to be different 
between Windows and Linux, the back end that processes commands and 
keeps the database can be OS independent though if file IO works with a 
standard library or the open/read/write commands are defined per OS. 
Windows, OSX and Unix should behave identically if only one process 
accesses the files and doesn't reopen them too quickly (which can be a 
problem on Windows as the function returns before the lock is released. 
It's also more resource intensive on this system I think).

A 32bit executable will work without trouble on all 64bit Windows 
systems, so it's not necessary to target them separately.

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

The most common option seems to be C(++), although there are a few 
caveats with types that have different sizes on different platforms. The 
service only needs very basic network and file IO though, which is 
available with any language.

A higher-level platform-independent language like Python would make 
compatibility much easier but I don't know if there is one that works 
without a standard library or framework. Python installations are not as 
common on Windows as they are on Linux from what I've seen.

A platform-independent language that compiles to native executables 
would be the best option, it just has to be common enough to be 
maintained in open source/non-profit software.

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

On Windows it's very common to have bundled dependencies, so having a 
small redistributable installer should not be a problem. It would have 
to register itself for uninstallation and exit without changes if a 
newer version is detected.

The protocol has to be backwards compatible for this to work, which 
would be possible by not removing or changing old commands. A version 
command would work too, but it would make connections stateful.
I think the best option would be to create a second Add/Update command 
if there's a breaking change. With a binary protocol, this would just 
mean sparse command ids and could be completely hidden if there's a 
client library (which shouldn't be part of the main project and would 
only implement one protocol version at a time, for one environment).

On OSs with package management it would certainly be better to use that 
to manage the dependency, but you're right that there would be some work 
to get it included in the necessary repositories.
I think the "significance" of the package is not really an issue, on 
Ubuntu for example many app localizations have their own package.

I have no idea how installations work on OSX, but one of the above 
solutions should work. The package could behave just like the 
redistributable installer, so there would be no conflict if both were 
used. Maybe there could be a small flag/file for each of them so the 
program only disappears if both are removed.

I think that redistributables on Windows can be marked as dependency in 
a similar way to prevent removal, but it's not commonly used. It would 
be better to just warn the user if the program can't be found, along 
with a link to a download page. cypherpunks.ca already hosts the Pidgin 
plugin so I assume it would be possible to host the installer for users 
who removed the dependency. It can be the same file as the 
redistributable, I think that's what Microsoft does with their frameworks.

I don't see how the name should be an issue, it hardly matters because 
the average user won't interact with it directly. How does 
"Off-the-Record Address Book" sound? It would be clear what it does when 
it appears in the software list and it's by far long enough to prevent 
collisions in a package manager. (It could be shortened to otr-... there 
if the verbose name is too long, both aren't taken. The Windows name can 
and should be relatively verbose though.)