Reproducible builds

Starting with version 1.12, the Shadow server now supports reproducible builds.

Making one’s source code open and publicly available for inspection is only one side of transparency. The other side is to confirm that the published binaries are indeed built from this very source code without any alterations, backdoors, and so on.

This means that one can validate whether the pre-compiled jar file published on our downloads page is really built from exactly the same source code as published on our GitHub page. This validation is done by building the jar file from the source code, calculating its checksum and comparing the latter with what is published on our website. If the two checksums match, then there are no alterations.

Making a build reproducible is a tricky task, since the checksum may differ for different build environments even if there are virtually no changes in the source code. Reproducibility must be supported by the source code itself and by the compiler, but the final piece is to provide the same build environment every time. That is why we use Docker for reproducibility. Our respective documentation page specifies the relevant Dockerfile and brief instructions.

We hope to announce support for reproducible builds for our Android client as well in the near future.

The Shadow is cast

The need for the open-source on-premises secure messenger solution has been manifesting itself throughout the recent years when end-to-end encryption became a de-facto standard in the world of secure messaging. We are humbly attempting to address this need with the launch of Shadow, which:

a) is fully open-source (both for its client and server parts)
b) uses end-to-end encryption as its only mode (no optional and all that!)
c) puts the system server under your own administration – in contrast to all the mass market solutions out there where you have no control over what’s happening behind the silver (or dark) lining of the cloud.

Shadow is built on the Signal secure messenger, as we believe Signal to be the leader of the secure messaging technology. Preserving the best features of Signal, Shadow is anticipated to develop towards the needs of (relatively) small teams and the B2B market, which (again!) is in contrast to mass market solutions targeted at huge audiences of millions of individual subscribers.

Here’s a brief list of what’s different in Shadow versus Signal.

  • There’s no binding to phone numbers (and to the mobile network in general). As long as you have an internet connection, your device may even do without a SIM card. Instead of E.164 numbers we use alphanumeric user logins which are set by the system administrator (that is, by you), and are under your full control. Hence, no more SMS or callback verifications. The system directory is maintained on the server and any change is communicated to the clients.
  • As it quite naturally follows from the above, there are no complications such as Signal‘s “Contact Discovery Service” or registration lock with a PIN.
  • Registration in the system is a three-step process which is fully controlled by the system administrator – firstly, the would-be end-user scans the registration QR code provided by the administrator, next s/he enters the user login (which is set up and provided by the system administrator as well), and thirdly, s/he enters the one-time password (which, as you probably have guessed, is provided by the administrator). In this process, there is really very small opportunity for a malicious party to register on your server in the first place, so your client base is trusted as long as you trust each of your individual end-users.
  • There’s no reliance on public clouds (such as Amazon or Google) for storage. Instead, the server part of the solution includes a private cloud component where all profiles, attachments and debug logs are stored. Of course, we still need to rely upon Google Cloud services for push notifications or geotargeting.
  • The fact that the system server is under your own control lets you customize some service level parameters – for example, set your own FCM (Firebase Cloud Messaging) Sender ID or configure the email address whence debug log reports would be sent.
  • We provide detailed system administration documentation – which is not free of charge, – but there is also the freely available Quick Start guide which provides enough information on how to launch and operate the service. And, of course, our source code is public (but this is not a difference from Signal).

This is just the beginning of the way, and we hope to be able to add more features in the not-so-distant future.

In these uneasy times when whirlwinds of danger are raging around us, may Shadow be your shade and shelter.