Debian to shift to a modern GnuPG

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

The GnuPG project maintains several active branches that differ in algorithm support, API, and other important details. In most cases, multiple branches can coexist on a single system, but only one provides the default /usr/bin/gpg executable in any given configuration. Debian recently announced a decision to switch its default gpg from the "classic" branch of GnuPG to the "modern" branch, which will trigger several other changes for users and package maintainers.

GnuPG is currently developed in the "classic" (1.4) branch, the "stable" (2.0) branch, and the "modern" (2.1) branch. The classic branch provides a monolithic gpg binary, while both the stable and modern branches are modular. In particular, the cryptographic functions in the newer branches are provided by libgcrypt, and passphrases for the active session are managed by the gnupg-agent daemon rather than by the gpg binary directly. There is also a separate S/MIME module available for newer branches, while GnuPG classic lacks S/MIME support. Furthermore, while classic and stable support the same set of encryption and hash functions, GnuPG modern adds support for several new algorithms (most notably elliptic curve cryptography).

Thus, there are several advantages to moving to the newer branches, although the GnuPG project still suggests the classic branch as a good choice for servers and embedded systems. On the other hand, GnuPG modern introduces a change to the way keyrings are stored on disk, which could potentially cause migration pains if care is not taken. Specifically, in the earlier GnuPG branches, a user's private keys were stored in a separate file (secring.gpg) from their public keys (in pubring.gpg). But the public half of a user's own key pair was stored in both secring.gpg and pubring.gpg, meaning that steps were needed to keep the two in sync. This is clearly less than ideal.

In GnuPG modern, the keys are all stored together (although in an improved format that is easier to parse) and the gpg-agent program simply keeps track of which ones include a private component. The first time GnuPG modern is run on a system with the old-style keyring files, it performs a one-time conversion to the new format. The conversion is painless, unless some package unwisely makes assumptions about the way the ~/.gnupg directory is organized. But it is one-way; users wanting to revert to the old format should expect to do a significant amount of work.

Debian has always used GnuPG classic as its default, while allowing stable to be installed in parallel: classic provided the /usr/bin/gpg binary and stable provided /usr/bin/gpg2. Many other distributions have moved on from GnuPG classic already, although providing separate packages for both gpg and gpg2 seems to be the approach taken by Fedora and several others. Even in comparison to those distributions, however, Debian's decision to stick with stable instead of modern garnered periodic complaints. On August 3, Daniel Kahn Gillmor announced an upcoming change in an entry published on the Debian Administration blog. The distribution will soon begin packaging GnuPG modern under the "gnupg" package name, drop GnuPG stable, and repackage GnuPG classic as "gnupg1."

The /usr/bin/gpg binary will be provided by GnuPG modern, and /usr/bin/gpg2 will be a symbolic link to it, in order to prevent breaking any existing user scripts written explicitly for the newer GnuPG. And the old package will still be available for those who need it. There are some plausible reasons to need the old package, such as the ability to access archives encrypted using old, unsupported encryption algorithms or obsolete key formats (e.g., GnuPG modern drops support for the insecure and 20-year-old PGPv3 key format).

Gillmor cited several advantages to the change. Access to newer key algorithms and GnuPG modern's improved key storage are clear benefits. In addition, GnuPG modern uses a separate daemon (dirmngr) to query keyservers. The dirmngr process is persistent, so it can monitor the availability of keyservers (eliminating time-out problems caused by querying a keyserver that has gone offline). The daemon can also route all queries over Tor and it can use the sks-keyservers.net Certificate Authority (CA) to secure key requests with TLS without resorting to placing trust in a public CA. While it is possible to configure GnuPG classic for use with Tor or the sks-keyservers.net CA, built-in support is more convenient.

Gillmor also pointed out that the human-readable output of GnuPG modern's --list-keys command is improved over classic's output. The newer branch no longer displays short key IDs (which were called out for the possibility of collisions in June), but does list full key fingerprints and the user-ID validity values (e.g., ultimate, fully, or marginal), as well as the flags that indicate which subkeys are used for signing, authentication, and so on.

Impact

For end users, the switch to the new branch will likely only be noticeable in a few situations—and perhaps only if one is looking carefully. For instance, the gpg-agent process will prompt the user for the passphrase to unlock a key, rather than the gpg process, but the workflow itself will not be altered otherwise. Users who have existing keyrings on their machines will have those keyrings automatically updated to the new storage format the first time that they run GnuPG modern but, again, the transition is transparent enough that it is not likely to be noticed.

That said, there will be one immediately noticeable change for users on non-English systems, since the updated Debian packages split out the internationalization files into a separate package called gnupg-l10n.

On the other hand, the change will likely mean some work for Debian package maintainers, depending on how their packages use or depend on the old GnuPG. A number of packages include a Depends: gnupg configuration parameter but only use GnuPG to check signatures. For those packages, Gillmor suggests changing the dependency to the standalone signature-checker gpgv instead. This is a stripped-down program built from the GnuPG sources; Debian provides it as a separate package for convenience.

Packages that try to parse the contents of a user's ~/.gnupg/ directory are likely to break if they expect to find the old storage format. However, attempting to directly read that data is likely to be a bad idea anyway; GnuPG provides functions to access the keyring, and bypassing the official commands is of questionable wisdom.

Somewhat more defensible would be for a package to try parsing the human-readable output of the gpg command-line tool. Such packages will also encounter trouble after the changeover, because of the change in GnuPG modern's output format. But, Gillmor noted in the announcement, reliance on the human-readable output is a mistake anyway. GnuPG can produce colon-separated machine-readable output with the --with-colons switch; that output is easier to parse and is not changing format with the move to the new branch.

The announcement also notes that, although the gpg2 binary will exist as a symbolic link to gpg for now, it may go away some time in the future, so all package maintainers would be wise to examine references in their code and update accordingly.

The updated gnupg package and newly renamed gnupg1 package are currently in Debian experimental. A few bugs popped up so far but have been addressed; assuming that the packages seem to reach stability, they will shortly thereafter be added to Debian unstable, the next step along the path to eventual inclusion in a stable release.