OTR Next Generation library
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:
- libgcrypt 1.8.0 or newer
- libotr 4.x
How to install
To generate project configuration:
$ autoreconf --install
To configure the project:
To build and install:
$ make && make install
To run the tests:
$ make test
Configure and install the library with other options
To configure the project with OTRNG debug output:
./configure CFLAGS="-ggdb3 -O0 -D DEBUG_API=yes"
To configure the project with debug option using
$ ./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
$ ./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
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_send can be used as starting points for investigation of 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
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.