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

Tamme Schichler tammeschichler at googlemail.com
Sat Sep 21 04:41:30 EDT 2013


Am 20.09.2013 23:15, schrieb Paul Wouters:
> On Fri, 20 Sep 2013, Tamme Schichler wrote:
> 
>> I finished refactoring and documenting my otr-store draft, it's at
>> https://bitbucket.org/Tamschi/otr-store for now. It's a Mercurial repo,
>> I can switch it to Git if that's a problem though.
> 
> Some quick comments. I'd use .tar.gz, not zip. Also, please don't use
> filenames with spaces in them. Customary files names for license files
> is LICENSE or LICENSE.txt.

Changed to LICENSE.txt. I used the other name out of habit (easier to
include in a C# build) but this seems a lot better here.
I'm not sure what you mean by .zip vs. .tar.gz. As far as I know neither
of them is currently in the project and Bitbucket's snapshot download
supports both.

> Maybe look at pypi for packaging with a "setup.py"? That makes it easier
> for people to install and build packages from.

It's probably a bit early right now, but I'll look into it. Thanks!

>     #TODO: Dynamically find free port and write that number into a file.
>     port = 12534
> 
> Dont use temp files. I'm not sure why you should use ports, instead of
> named pipes of sockets? More interopability?

The main reason is that I myself can't use the better alternatives. I
know only very little about Linux and nothing about the Win32 API, so I
can't write the necessary modules. The loopback socket needs to be
replaced before really using the service due to the security issues
mentioned by subharo and dkg.
The file with the port number would be there to communicate it to other
processes, but that wouldn't be necessary with domain sockets or named
pipes because there is no potential namespace conflict with those solutions.
The current program is mostly a proof of concept/structural outline.

> I'm not sure what you mean with:
> 
>     This project aims to create an easy-to-use and robust API for sharing
>     Off-the-Record identities and possibly contacts between IM clients on a
>     single device and user account.
> 
> I'm not sure what you are trying to solve. If you are creating a
> "broker" between different IM programs, wouldn't it be better to
> standarize the format (which I would like to do, based on the
> libotr/pidgin-otr format) and just ensure various software can
> read/write that? Because to use your API, it needs _some_ kind
> of standard anyway? So why implement a middle man?
> 
> I'm nervous storing my private keys into a "broker". I'd rather use
> something like unix permissions plus SElinux labels to restrict access
> to a .config/otr.* files.
> 
> Paul

The main reason for the broker is to reduce complexity. Initially
writing the system takes a bit more work because the service needs to be
robust and as cross-platform as possible but after that using it from a
client is very simple, much simpler than processing and updating a file
in a failsafe way. Another benefit is that the service can be extended
if that becomes necessary while extending the file format could break
compatibility with previous versions.

I've also had some negative experiences with exchange file formats.
Basically: If there's any way to write two incompatible programs with a
common specification it will happen (and in many cases is more likely
than a fully working exchange). Even if the specification is strict,
there are usually implementations that work for the most part but don't
get it 100% right. It seems that OTR suffers from this too, to some extent.
The broker can enforce the specification and validate any data it
processes, so it acts as a test-suite at the same time. Implementation
errors in the consumer will hopefully be immediately apparent even if an
IM client is only tested by itself.

The bottom line is, it's a lot more difficult to create and especially
use a file format standard than you think. The broker removes a lot of
this complexity from the consumer side to make adding compatibility to
an IM more attractive. It also reduces overall work because there's no
file format library to be ported or reimplemented in different languages.


Regarding your security concerns: With domain sockets and named pipes it
should be easy to reach the exact same security as with file permissions
and an IM application running in user-mode, as both support access
permissions. The only applications that should be able to access it are
those running in your context.
SElinux has domain socket permissions[1], so there's no leak that way
either with the right configuration.

-Tamme

[1]:
http://www.nsa.gov/research/_files/selinux/papers/freenix01/node10.shtml



More information about the OTR-users mailing list