FAQ

GPG according to XDG specifications — Backups management

NOTE: the answers to these questions are only my own opinion; in no case do they correspond to an absolute truth!

---

Why don't you use GPG according to XDG specifications?

First of all, it is important to know that Arch Linux already creates a GnuPG service and activates it for us. In addition, one good thing to know is that since version 2.1 of gpg, it is no longer necessary to configure GPG_AGENT_INFO.

In the past, I had to set the GNUPGHOME environment variable in my xdg file:

export GNUPGHOME="$XDG_CONFIG_HOME/gnupg"

This one, allowing to indicate to GPG that the configuration file is no longer in the home, but in the locality filled by this variable.

However, this configuration has the issue that there will exist two gpg-agent running on your machine. The systemd one (default) and the one created by the user, notified by an extra folder in /run/user/$UID/gnupg.

This will cause some problems. Especially if you create a systemd service unit (e.g. mbsync.service) that needs to use gpg-agent:

[Unit]
Description=Mailbox synchronization service
Wants=network-online.target gpg-agent.socket
After=network.target network-online.target dbus.socket gpg-agent.socket

[Service]
Type=oneshot
ExecStart=mbsync -c /home/someone/.config/isync/mbsyncrc -a
Environment=MU_HOME="%C/mu"
StandardOutput=syslog
StandardError=syslog

Indeed, even if it is informed about the systemd service unit to use gpg-agent, it will always return a GPG key decryption error.

NOTE: the extra directory are used when you use a non-default gpg home. The reason of this is that the hash has the length option of a unix socket name which is limited (~ 108 characters).

So, while waiting for the next releases of gpg to handle this unix socket length issue, gnupg is in the home (~/.gnupg).

How do you manage your backups?

For my daily backups, I use BorgBackup, which is a backup deduplication program with optional compression and authenticated encryption. This program supports all rsync features, with the added benefit of remote side encryption.

Avoiding as much as possible the Clouds and servers that do not belong to me, all my backups are done on my 1TB external hard drive. In order to be able to use BorgBackup properly, you must create a repository at the place (e.g., an external hard disk) where you want to make your backups. Assuming that you want to create a repository on an external hard disk whose UUID partition is 181E9F1E1E9EF44A, then the command will be:

borg --encryption=keyfile-blake2 /run/media/$USER/181E9F1E1E9EF44A/borg

NOTE: BLAKE2b is faster than SHA256 on Intel/AMD 64-bit CPUs (except AMD Ryzen and future CPUs with SHA extensions).

When the command is executed, you will be asked to enter the passphrase to unlock the AES-CTR-256 encryption key (by default, stored in the same location as the repository), which will be used to encrypt and decrypt your data. As we used keyfile-blake2, the AES-CTR-256 encryption key will be stored in ~/.config/borg/keys.

TIP: I recommend you to generate a strong password, with password-store.

Thus, all my backups are done every week, through an Bash script and for easier detection of the external hard disk (optional, if you are using a remote server) from this script, I created a /dev/backup-disk block device symlink. To do this, I had to create a /etc/udev/rules.d/40-backup-rules file that contains this udev rule:

KERNEL=="sda", SUBSYSTEM=="block", SUBSYSTEMS=="usb", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SYMLINK+="backup-disk"

NOTE: this udev rule must be modified according to your device. To do so, consult this guide.