Before you try to build libotr-ng, verify you have installed:
- autoconf - https://www.gnu.org/software/autoconf/autoconf.html
- splint - http://splint.org/documentation
- valgrind - http://valgrind.org/. At least, version 3.12.0
Then, install the following dependencies:
- libglib2.0-dev
- libgcrypt 1.8.0 or newer
- libgoldilocks
- libsodium-dev
- libotr 4.x
To generate project configuration:
$ autoreconf --install
To configure the project:
$ ./configure
To build and install:
$ make && make install
To run the tests:
$ make test
To configure the project with OTRNG debug output:
./configure CFLAGS="-ggdb3 -O0 -D DEBUG_API=yes"
To configure the project with debug option using gdb:
$ ./configure CFLAGS="-g -ggdb3 -O0" CXXFLAGS="-g -ggdb3 -O0" LDFLAGS="-g -ggdb3" --disable-shared
$ gdb [path/test/executable]
To configure project with debug option using lldb:
$ ./configure CFLAGS="-g -ggdb3 -O0" CXXFLAGS="-g -ggdb3 -O0" LDFLAGS="-g -ggdb3" --disable-shared
$ lldb [path/test/executable]
To configure project with debug option:
$ ./configure --enable-debug
To run make code-style:
Install:
- clang-format-3.5
This library is primarily meant to be used by instance messaging clients to
provide OTRv4 encryption on top of the library. The main entry points for the
functionality can be found in client.h - the functions otrng_client_receive
and otrng_client_send can be used as starting points for investigation of the
functionality.
The libotr-ng library is not inherently thread safe. Since the library is
meant to be used in widely different environments with different threading
libraries and process requirements, it would be difficult for the library itself
to use a specific thread safety paradigm. Thus, the client application will have
to ensure this.
Almost all functions in this library are safe in the sense that they only modify structures and memory that has been explicitly sent in as arguments to the functions. There is no global state in the system, with the exception of the out-of-memory handler. This means that it is possible to concurrently call functions as long as they don't modify the same memory area. However, for large chunks of the OTR functionality, the functions will touch on central areas relating to lists of clients.
The limit of interaction between OTR functions is guided by
the otrng_global_state_s structure - for client instances that are part of d
ifferent global states, it is completely safe to call functions concurrently.
In terms of how to ensure thread safety, the easiest way would be to make sure there's always a lock around calls to OTR functionality, so that only one call from a client to the library can happen at the same time. Another way would be to always serialize calls using a message queue. Another way would be - like in Pidgin - to not have multipled threads at all. However how you choose to do it, it's important to ensure this thread safety, since the results of not doing so can be potentially very dangerous.
The work made hare was partially supported by the NlNet Foundation. Find information here.
