Hello World.

Refreshing GPG keys on Arch Linux with GnuPG 2.1, parcimonie.sh and a tinfoil hat

Neal Walfield gave a talk at 32C3 called “An Advanced Introduction to GnuPG” (slides, there is no recording as it was held in one of the smaller workshop rooms) which gave some insights on the data formats used by GnuPG, its architecture and showed some good practices. One of these practices is to use a tool called parcimonie instead of gpg --refresh-keys to fetch updated keys from the key servers.

parcimonie is a daemon that sleeps most of the time but every now and then picks a random key from you GnuPG keyring and refreshes this key over Tor. The idea is not to leak your whole address book every time you refresh these keys in bulk, but to fetch a single key at a time over a fresh Tor circuit in order not to leak any information.

But parcimonie is written in Perl and as I use Arch Linux, I would have to manually install many dependencies. But luckily there is a rewrite in Bash, called parcimonie.sh that has less than 200 lines of code. It can easily be installed from AUR.

But if it was that easy, I wouldn’t write a blog post about it, so here comes the part of getting it running as there is a bug that we need to work around. The AUR package provides a parcimonie.sh@.service systemd unit which we will use. You could go ahead and just enable and start parcimonie.sh@all-users.service which would do some magic to start a parcimonie.sh instance for all users users on the system that have a ~/.gnupg directory. But as the title of this post already mentioned, I want to add a tinfoil hat to the mix and avoid running parcimonie.sh as root at any time.

So as I want to run parcimonie.sh for my user julian, I created a config file at /etc/parcimonie.sh.d/julian.conf with the following contents:


The options PARCIMONIE_USER, TOR_ADDRESS and TOR_ADDRESS should be self-explanatory. I specify a TMP_PREFIX within my home directory as I’m not fully trusting the parcimonie.sh code in this aspect: it does not use mktemp but generates some random number, appends it to the prefix and uses that file path. Even though there should be no malicious users on my laptop, that should prevent any theoretical symlink attack. The last option, GNUPG_KEYSERVER_OPTIONS is just a workaround for issue #15, which happens on Arch Linux with GnuPG 2.1.

Now you could start parcimonie.sh@julian.service and it would work, but parcimonie.sh would be started as root and use su to switch to the actual user it’s supposed to be running as. But luckily systemd has a concept of drop-in files which we can use to extend existing unit files, just create a file /etc/systemd/system/parcimonie.sh@julian.service.d/user.conf with the following contents:


Now we can finally start parcimonie.sh:

systemctl daemon-reload

# Verify that the drop-in is applied
systemctl cat parcimonie.sh@julian.service

systemctl enable parcimonie.sh@julian.service
systemctl start parcimonie.sh@julian.service

# Verify that everything is running fine
systemctl status parcimonie.sh@julian.service