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

[Tamme Schichler]

Am 09.09.2013 18:48, schrieb subharo at hushmail.com:
> On Sun, 08 Sep 2013 21:49:34 -0400 "Tamme Schichler"
> <tammeschichler at googlemail.com> wrote:
>>> 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).
>>
>> 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.
>
> Actually, I personally think Python would be the best choice.  Why?
>
> -Python code is famous for being very tidy and simpler to read.
> This is important for a crucial security-sensitive program such as
> the one we're discussing, so security professionals can easily
> review the code and vet that there's nothing malicious in it.  In
> my opinion, reviewing perl code is much harder, as it's much
> uglier, IMHO, and there seems to be about 6 ways to do pretty much
> anything and everything (and no two perl programmers are likely to
> do everything in the same way, to anywhere the degree you'd see two
> developers developing python code that has similar functionality).
> A perl code reviewer may be frustrated at the need to learn some of
> 6ish alternate ways wherever appropriate, to do an effective review.
>
> -By using Python, I think it would help speed up development time,
> and minimize overall time to gain acceptance by the OTR community
> as trustworthy.  It takes way less Python code to accomplish the
> same job as comparable C(++) code.  I've heard that a ratio of 1:10
> (of lines of python compared to lines of C++) is common.
>
> -You can trust that any virtually linux distro already has Python
> available (certainly the top five), or failing that, it's easily
> installable from the package management system.  As to Windows,
> imposing a Python dependency on them is something I feel
> comfortable with.  Speaking tongue-in-cheek here: what security-
> conscious user (you know, the kind who wants to use OTR in the
> first place) would want to continue using Windows anyway, after
> hearing news like this?  "How NSA access was built into Windows":
> http://www.heise.de/tp/artikel/5/5263/1.html
>
> -Gajim (which supports OTR) notably uses python already as their
> primary language.
>
> Cheers!
>

If only switching away from Windows was that easy :)

Python is perfect on Linux, but on Windows it's unfortunately so 
uncommon that almost no-one has it installed. A possible reason could be 
its size: About 15 or 20 MB for Python 2 and 3, respectively. That's 
huge compared to the ~10 MB installers most messengers have.
The IM installers would definitely need to bundle Python or download it 
automatically, similar to Pidgin and its GTK+ (with the exception that 
installing it normally would most likely be fine, if there's a --silent 
option).

A possible workaround would be compiling the script with PyInstaller or 
py2exe which packages part of the Python environment into a single file. 
The service would be most likely larger but external dependencies should 
shrink to a version of the MSVCR only, which is <1 or around 5.5 MB 
depending on the licensing terms. py2exe is pretty popular according to 
http://www.py2exe.org/ , but I don't know whether it works with Python 3.

Something that could work is installing a compiled (.pyc) version of the 
necessary framework components into the service's directory. (I just 
found out about this possibility after installing Gajim, though Blender 
and GIMP also have their own, larger, installations.) If this is 
possible it would probably be the best option for compatibility on 
Windows and small enough to ship with the default installer.


That said, I briefly worked with Python on a file parser. I definitely 
agree on the about 1:10 ratio, and working with binary data is 
incredibly easy in this language. I think I would be able to contribute 
to the development if nothing unrelated comes up.

Maybe we should continue on [OTR-dev], as most users likely aren't too 
interested in this discussion at this point.