Signal on OpenBSD
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 https://gitlab.com/h3artbl33d/libmatthew.git /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 gmake 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
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 https://github.com/AsamK/signal-cli.git /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
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
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.