Package Insurance

Many distributions develop, test, build, and distribute their software via a heterogeneous zoo of servers, mirrors, and workstations that make central management and protection of the end product almost impossible. In terms of personnel, distributions also depend on the collaboration of a severely limited number of international helpers. This technical and human diversity creates a massive door for external and internal attackers who seek to infect popular distribution packages with malware. During updates, then, hundreds of thousands of Linux machines download and install poisoned software with root privileges. The damage could hardly be greater.

The danger is less abstract than some might think. Repeatedly in the past, projects have had to take down one or more servers after hacker attacks. The motivation of (at least) all the major distributions to protect themselves from planted packages is correspondingly large and boils down to two actions: one simple and one cryptographic.

Advanced Mathematics

Armed with a checksum, users can determine whether a package has passed through the Internet without error. The MD5, SHA1, and SHA256 hash methods are popular ways to calculate a checksum for a package.

Because checksums provide no protection against intentional tampering, Arch Linux and Debian and its derivatives also sign their packages and repositories. They naturally use public key cryptography to do so. The basis is a key pair. Using the private key, which is kept safely, the project team signs the new packages or the repository. With the public key, which is accessible to everyone through the distribution sites and installation media, users can check whether the signature originates from the owner of the private key and thus comes from the project.

Secrecy

To improve security, some distributions rely on a chain of signatures and checksums, although the project websites reveal little detail about how exactly they do this or what the technical implementation looks like, with sparse information spread over several subpages and obsolete pages. Therefore, you have no way to learn about the internal organizational processes concerning which team member signed which packages, with which key, and when or whether it even happens automatically. The processes at least can be reconstructed to a certain extent for Arch Linux, Debian, Fedora, openSUSE, and Ubuntu distributions.

Arch Linux

The makers of the Slackware-style rolling release distro with Debian-style package management rely on GnuPG and the web of trust concept [1]. A developer first puts together a suitable package for their software and self-signs it using GnuPG. Then, the developer uploads the package to the Arch User Repository (AUR) and initially retains responsibility for the package. If the package proves itself in the repository, it moves into the community repository.

The AUR and community repository are managed by selected Arch Linux users referred to as trusted users [2], each of which must sign the packages they manage with their own GnuPG key. If the Arch Linux team happens to classify one of the packages as particularly important, the package is promoted to one of the other official repositories, such as core or extra . The packages in these repositories are managed in turn by the Core Arch Linux developers.

The project has five official GnuPG keys, known as the master signing keys (Figure 1). Each key belongs to one of five Arch Linux developers [3]. At least three of these developers always sign a key belonging to the package developers and the trusted users, who in turn sign the packages themselves with their certified keys. The signature for a package is kept in a separate file with a .sig suffix; the repository serves this up along with the package.

Figure 1: In Arch Linux, the six master signing keys are used as a starting point for a chain of signatures.

Because the web of trust is created in this way, the Pacman package manager can now check the signatures: As soon as a package is signed with a key, which in turn is signed with at least one valid master signing key, it is therefore assumed to come from the Arch Linux project.

Each of the master signing keys has a revocation certificate that lies in the trusty hands of another independent Arch Linux developer. This setup prevents one of the master key holders obtaining sole power over the certification process. The packages that reside in a repository are revealed by a small database. It contains the corresponding MD5 and SHA256 checksums for each package.