Signal on OpenBSD

by on under communication
3 minute read

Signal is my primary means of communication to keep in touch with friends, family, acquintances and even customers. It has a neat UX and uses end-to-end encryption - always. Despite it’s sole focus on security and privacy, the desktop client uses Electron; which is basically an outdated and vulnerable Chromium wrapper. I consider this to be a poor design - but that is a discussion for another time. Due to the usage of Electron, the desktop client is unavailable with OpenBSD. Having to grab my mobile phone for every damned message I’d like to send or receive is far from practical; it’s ineffecient as fuck. So why not tackle ‘em both and use a commandline client?

Moxie, the founder of Open Whisper Systems and Signal is hostile toward third party clients. Hence, there isn’t a very broad ecosystem around Signal. But luckily, some developers share the attitude that a messenger like Signal shouldn’t run inside a browser and started the signal-cli project. As the name implies, it is a commandline client - or rather a library. For more efficiency, you’ll need a frontend - we’ll get to that in due time.


Unfortunately, Signal is developed in Java. Since signal-cli uses a patched version of the official library, we’ll need Java as well. Please note that this guide is written with Java 8, I haven’t tested it properly with Java 11. During the dependency installation, pkg_add will ask which Java version you’d like to install; answer 1.8 unless you are out for an adventure and don’t mind editing Makefiles.

Install the tools we’ll need to compile some libraries:

doas pkg_add jdk gmake gcc

While signal-cli is able to function without libmatthew, it is a requirement to daemonize signal-cli. Grabbing the official sources and compiling them didn’t work. The Makefile wasn’t written with BSD in mind and some source files (unix-java.c) are untouched for over a decade. Rather than whining and accepting my defeat, I threw extra time and effort in it. With the help of a dear mate, Gnunix, we were able fix the issues. I didn’t create a port out of it yet as I am unfamiliar with the whole porting process. So at least for now, you’ll have to use my fork.

Fetch the source code of libmatthew:

doas git clone /usr/local/libmatthew

Before compiling libmatthew, we need to tell it where to find the java utilities:

export PATH=/usr/local/jdk-1.8.0/bin:/usr/local/jdk-1.8.0/jre/bin:$PATH
export JAVA_HOME=/usr/local/jdk-1.8.0

Enter the directory, build and install it:

cd libmatthew
doas gmake install

This will install the libraries of libmatthew in the proper places so OpenBSD’s jdk is able to use it.

Next, delete the temporary files:

doas rm -Rf /usr/local/libmatthew

Installing signal-cli

Now that all the dependencies are in place, you are able to build signal-cli and making it available through the following commands:

doas git clone /usr/local/signal-cli
cd /usr/local/signal-cli
doas ./gradlew build
doas ./gradlew installDist
doas ./gradlew distTar
doas ln -s /usr/local/signal-cli/build/install/signal-cli/bin/signal-cli /usr/local/bin/signal-cli

Picking a client

While signal-cli is theoretically sufficient to send and receive messages, you’ll probably want a client for more efficient usage. There are a couple listed on the wiki.

Please bear in mind that you need to set the JAVA_HOME variable upon usage. An easy way to achieve this is by putting it in your .profile:

export JAVA_HOME=/usr/local/jdk-1.8.0

If your pick refuses to run or throws some errors, try compiling/installing it from it’s own directory in /usr/local. The reasoning is simple: that partition has the wxallowed flag set, which is unfortunately required by an insane amount of applications.

openbsd, signal, cli