Package Insurance

Beyond RPM

The openSUSE project relies on the same principle as RPM to secures its repositories in the repomd and Yum formats. A signature from the separate repomd.xml.asc file underpins the central repomd.xml file. The public key required for verification is either identical to the one provided by the installation medium (e.g., an update repository), or it is located in the repomd.xml.asc file. If the key is unknown to the system, the user has to trust it explicitly.

The repomd.xml file contains a list with other files in addition to their corresponding SHA256 checksums. These additional files are then given, among other things, a list of all the packages contained in the repository. Again, a chain of trust is built: If the signature of the repomd.xml file is okay, the checksums it contains are trustworthy. In turn, you can use these checksums to discover whether the associated files in the repository have been tampered with.

Ubuntu

Ubuntu secures its packages on the same principle as its Debian roots, but Canonical signs the release file. Because Ubuntu takes over most of the packages from the Debian repositories, Canonical even recommends that Ubuntu developers submit their programs [12] to Debian first.

The personal package archives (PPAs) are a minor exception. Each developer can set up their own repository on the Launchpad platform and deliver their software for Ubuntu users. Launchpad creates its own cryptographic key for each PPA, which the platform uses to sign each package offered by the PPA automatically [13]. In the background, the same system as in Debian is in place here: A PPA comprises a small repository with a release file, which Launchpad signs with the PPA key.

In contrast, developers need to upload the new Snaps [14] to the Canonical store much like smartphone apps. There, the software goes through an automatic – and on a case-by-case basis, manual – review process.

Principle of Hope

Foisting a poisoned backdoor package onto a distribution would be the perfect attack vector for a hacker. The motivation of each system to prevent such a scenario should be pretty high. In their wikis, all distributions discussed here describe in detail how users should check the origins of a package, but they provide surprisingly little information about their own organizational and technical background processes. This kind of obfuscation is a poor match with the kind of transparency that open source seeks to achieve and might possibly originate from a desperate attempt at achieving security through obscurity.

Debian, Ubuntu, and openSUSE use only a single GnuPG key to sign a central information file in the repository. Starting with this file, the package manager then checks the individual packages, which makes the central key the most attractive point of attack.

Only Arch Linux tries to defuse the problem with five master keys. However, it remains unclear in many cases where and how the project keeps the private key it uses for signing.