« Previous 1 2 3 4
Digital signatures in package management
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.
Infos
- Pacman/package signing: https://wiki.archlinux.org/index.php/Pacman/Package_signing
- Arch Linux trusted users: https://wiki.archlinux.org/index.php/Trusted_Users
- Arch Linux master signing keys: https://www.archlinux.org/master-keys/
- Debian archive signing keys: https://ftp-master.debian.org/keys.html
- Debian FTP Master team: https://ftp-master.debian.org
- Sigul: https://docs.pagure.org/releng/sop_create_release_signing_key.html
- Fedora FAQ for package signing: https://getfedora.org/keys/faq/
- Fedora package signing keys: https://getfedora.org/keys/
- Fedora release package signing: https://docs.pagure.org/releng/sop_release_package_signing.html
- Open Build Service: http://openbuildservice.org
- openSUSE secure installation sources: https://en.opensuse.org/SDB:Secure_installation_sources
- Ubuntu packaging guide: http://packaging.ubuntu.com/html/
- Personal package archives: https://help.launchpad.net/Packaging/PPA
- Snaps: https://snapcraft.io/docs/build-snaps/publish
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.