Package Insurance

openSUSE

Each individual SUSE RPM package is signed with a GnuPG signature, which can be found in the metadata of the RPM package. Typically, SUSE distributions are created automatically in the Open Build Service [10], the public development platform operated by openSUSE. The GPL software of the system automatically signs all the packages and media that pass through it.

When asked, Ludwig Nussel, the release manager of openSUSE Leap, reported that a private signing host is connected to the build service via a separate cable; the private portion of the official key pair resides on this host. Only employees with special security clearance have access to the server room, not even release chief Nussel is allowed in. He assured us that nothing runs on this computer (not even an SSH server) except the signing service. Logins are possible only via a serial console.

SUSE Key as a Backup

In any openSUSE installation, the public parts of two keys are preinstalled in the content.key file: The openSUSE project signing key opensuse@opensuse.org and the SUSE package signing key build@suse.de . SUSE has so far seen no reason to renew the keys, but they do have an expiry date, which authorized persons regularly extend.

Should the private openSUSE key be compromised, the project would use the SUSE key to distribute an update that deletes the compromised keys and rolls out a new openSUSE project key. SUSE's private key is stored in a separate infrastructure, like that described above.

Project Weaves Chains of Trust

Multi-level security similar to the Debian project is founded on the keys in the repositories and on installation media [11]: The core of this structure is the content file, which reveals the directory containing the packages. The Open Build Service signs the file before it is delivered, and the signature ends up in the content.asc file. The content file references other files containing the file names of all packages. For each of these files, content provides the appropriate SHA256 checksum.

The content file also references files with other public keys, which Yast imports without complaint, because content already has a trusted signature. The keys are designed to help users check the signatures in the RPM packages. Next, Yast uses the matching packages.gz file, as designated by the content file. It contains all of the packages in the repository with their corresponding SHA1 checksums.

In this way, a chain of trust is built up as in Debian. Packages that cannot prove their origin at install time are rejected by Yast; rpm also notices attempted fraud, but it is more forgiving in its response (Figure 4).

Figure 4: The rpm tool on openSUSE Leap notices the dubious reputation of a package, but installs it nevertheless.