Distributions

Debian to shift to a modern GnuPG

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.

Comments (6 posted)

Distribution quotes of the week

-- Stephen John Smoogen

-- David Kalnischkies

Comments (none posted)

Ubuntu 14.04.5 LTS released

The Ubuntu team has announced the release of Ubuntu 14.04.5 LTS (Long-Term Support) for its Desktop, Server, Cloud, and Core products, as well as other flavors of Ubuntu with long-term support. "We have expanded our hardware enablement offering since 12.04, and with 14.04.5, this point release contains an updated kernel and X stack for new installations to support new hardware across all our supported architectures, not just x86."

Full Story (comments: none)

Debian LTS default-java switch to OpenJDK 7 - Icedtea plugin

The default Java version in Debian LTS Wheezy has been bumped to Java 7, as Java 6 could no longer be supported. "To follow this change, the icedtea-plugin package has been updated to depend on icedtea-7-plugin rather than icedtea-6-plugin. icedtea-6-plugin is unsupported as it depends on Java 6."

Full Story (comments: none)

Fedora Account System (FAS) security issue

A vulnerability was identified and fixed in FAS. "The Fedora Infrastructure team identified a serious vulnerability in the Fedora Account System (FAS) web application. This flaw would allow a specifically formatted HTTP request to be authenticated as any requested user. The flaw was caused by a logic problem wherein the FAS web application would accept client certificates that were not intended to be supported. If the authenticated user had appropriate privileges, the attacker would then be able to add, edit, or remove user or group information." According to the team investigating the issue, they don't believe the flaw has been exploited.

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 673 (August 8)
• Linux Mint Monthly News (August)
• Lunar Linux weekly news (August 5)
• openSUSE news (August 10)
• Tails report (July)
• Ubuntu Kernel Team Weekly Newsletter (August 9)
• Ubuntu Weekly Newsletter, Issue 477 (August 7)

Comments (none posted)

Bedrock Linux gathers disparate distros under one umbrella (InfoWorld)

InfoWorld takes a look at Bedrock Linux, an experimental distribution that makes it possible to use software from other, mutually incompatible Linux distributions, all under one roof. "Bedrock Linux uses virtual file systems to map the contents of various distributions into each other. The setup process involves installing one of any number of common distributions, then "hijacking" it to turn it into a Bedrock Linux installation. Be prepared for some heavy lifting, though. Right now, the setup process involves compiling Bedrock Linux's userland from scratch in the base distribution, then adding other distributions. Specific scripts exists for Debian-based distros (such as Ubuntu), Arch Linux, Yum-based distros (Fedora, CentOS, OpenSuse), Gentoo Linux, and a number of others, but in theory, any Linux distribution can be added."

Comments (none posted)

Copperhead OS: The startup that wants to solve Android’s woeful security (Ars Technica)

Ars Technica takes a look at Copperhead OS. "Copperhead OS, a two-man team based in Toronto, ships a hardened version of Android that aims to integrate Grsecurity and PaX into their distribution. Their OS also includes numerous security enhancements, including a port of OpenBSD’s malloc implementation, compiler hardening, enhanced SELinux policies, and function pointer protection in libc. Unfortunately for security nuts, Copperhead currently only supports Nexus devices. Google's Android security team have accepted many of Copperhead's patches into their upstream Android Open Source Project (AOSP) code base. But a majority of Copperhead's security enhancements are not likely ever to reach beyond the its small but growing user base, because of performance trade-offs or compatibility issues." Copperhead ships with F-Droid installed by default, but without Google Play; LWN reviewed this distribution in February.

Comments (none posted)

Replicant 6.0 early work, upstream work and F-Droid issue

The Replicant blog reports that Replicant is being updated from Android 4.2 to Android 6.0 by Wolfgang Wiedmeyer. Among many other improvements, Replicant 6.0 should bring full device encryption and SELinux support. The F-Droid issue centers around the discovery of software that does not comply with the GNU Free System Distribution Guidelines in the F-Droid repository. "While the list of such anti-features is displayed in red when selecting an application in F-Droid, applications with anti-features are still listed aside compliant ones. This is also quite confusing since free software isn’t expected to contain such anti-features in the first place."

Comments (3 posted)