Last updated on June 12, 2020
Ever since I posted these two posts (here and here) of using ProtonMail Bridge on a headless WordPress/Linux server, ProtonMail Bridge has somehow changed a lot. It now has more support for non-graphical environments. For example,
gnome-keyring can be replaced with a command-line-based password manager called
pass. And ProtonMail Bridge now also has an option,
--noninteractive, to run without interaction. All this to say, using ProtonMail Bridge is pretty easy currently on headless WordPress/Linux servers. So I write this post to update how I use ProtonMail Bridge on my server now.
pass is friendlier to headless environments than
gnome-keyring is. However,
pass requires a GPG key. Moreover, when using ProtonMail Bridge with
pass on a headless server, it’s better to use a GPG key that doesn’t need a passphrase. So I had been reluctant to write this update because of too much to cover.
I’m now still reluctant to explain the details, so I only write commands to create a passphrase-free GPG key, set up
pass, and use ProtonMail Bridge in a headless environment in the mentioned new way.
Disclaimer: the practice described in this post is not safe. If the server is hacked, the ProtonMail credential may be easily obtained by hackers. So make sure the server is secure.
- pass — most Linux distributions should have this in their official repositories
- GnuPG — I guess most Linux distributions should already have this
- ProtonMail Bridge v1.2.7 — not sure if all distributions have this package. If not, an option is to download the
.debpackage from here for Debian-based distributions. For Arch-based systems, there are several packages in AUR. Another option is to compile from the source code on GitHub.
Step 1: create a passphrase-free GPG key non-interactively
The above command creates a basic GPG key, and its ID is ProtonMail Bridge. This key does not have a passphrase, so
pass does not need to ask users for a passphrase whenever it tries to use the key. The key does not expire. Don’t use this key for other things (such as encryption, signing, identity, etc.). It is not safe.
NOTE: Make sure the server has a firewall and is secure. If a hacker gets into the server, he/she can use this key freely to open the ProtonMail credential saved in
pass. So be careful!!
Step 2: set up
This creates a new password database in
pass calls the database password store). And the GPG key ProtonMail Bridge can be used to open the database. If the server is multi-purpose or even a machine for daily work, don’t save other passwords/credentials in this database. This database does not need any passphrase to open due to the passphrase-free GPG key.
After this step, we can continue on the old way of running ProtonMail Bridge in the background as described in this post. Alternatively, we can use the new way described in the following steps.
Step 3: start ProtonMail Bridge in command-line & interactive mode and set it up
The new way to run ProtonMail Bridge in the background does not allow users to interact with the
protonmail-bridge daemon. We have to set up
protonmail-bridge interactively in advance. First, start the
protonmail-bridge in command-line mode:
Login our ProtonMail account with
login command and record the username and password of the local SMTP server. Please refer to the step 1 in the old post for details if not familiar with this.
After setting up
protonmail-bridge and obtaining the required information (SMTP username & password), we can now use
exit to exit the interactive interface.
Step 4: run ProtonMail Bridge in the background
This step is where it is different from the old way. Now we just execute the following two commands to start
The above command also redirects the output message from
protonmail-bridge to a file called
bridge_log.txt. We can use
$ cat bridge_log.txt to see
protonmail-bridge‘s output message.
One thing important is that now
protonmail-bridge daemon is non-interactive, which means there’s no way to give commands to the background daemon. If we want to control or set anything in
protonmail-bridge, we always have to kill the daemon and then do the work with the interactive interface. This is a major drawback compared to the old way.
For example, if
protonmail-bridge logs us out for some reason and requires us to re-login to the ProtonMail account, in the old way, we can just do
$ echo "login" > bridge_input && echo "ProtonMail account" > bridge_input && echo "ProtonMail password" > bridge_input to re-login. On the other hand, with the
--noninteractive way, we’ll have to kill the
protonmail-bridge daemon, start
$ protonmail-bridge --cli, login, exit, and then start the background daemon again. Or another example is when we want to check the status of the daemon. In the old way, we can just do
$ echo "info" > bridge_input && cat bridge_output to see if the daemon is still working fine. While with the
--noninteractive way, we can’t issue the
info command to the daemon.
Also… to reduce GUI-related dependencies
For those who don’t like to install a lot of GUI-related dependencies on a server, we can compile and build
protonmail-bridge from the source code on GitHub. Just build the
build-nogui target with
make. See the PKGBUILD of this AUR package.