Package Insurance

Debian

To discover which packages are offered by a Debian repository, you need to check out the files distributed across several subdirectories with the name packages. The files also provide the MD5, SHA1, and SHA256 checksums determined for each package. The locations of the packages files are in turn revealed by a file named release, which tells you the associated checksum for each package file.

The Debian team signs release files with an automatically generated key, which the documentation alternatively refers to as the automatic signing key or "ftp-master" key [4]. Currently, each Debian release has only one FTP master key (Figure 2); formerly, the project team produced a new FTP master key every year.

Figure 2: The Debian project lets users download its key from this page, which includes keys for older versions and for versions no longer in use.

The team signs the release files of every stable Debian version with the automatic signing key in use at the time of release. Additionally, the Debian team signs stable releases with a stable key that is generated for the release. In any case, the signatures end up in a separate file: Release.gpg.

Debian only signs the release files for special releases (proposed-updates, testing, testing-proposed-updates, unstable, experimental) and the security archive with the FTP master key. The keys can be viewed and downloaded [4] for all Debian releases (Figure 2).

Oh, Really!

The FTP Master team, which is responsible for operating the Debian archive [5], is responsible for signing and key management. You can determine the authenticity of a package by inspecting the chain of signatures and checksums: If the signature of the release file is okay, the package manager can trust the content. In turn, the release file contains the checksums of the packages files with the actual packages. If the checksums match, the content of the packages files is also unchanged.

The checksums contained in the packages let the user track the integrity of individual packages. Also, every package comes with a text file, which stores the MD5 checksums of all included files.

Before a package lands in an official Debian repository, the developers need to find an approved maintainer. As the sponsor, the maintainer checks the package and then uploads it to a repository after assessment. The Debian project distinguishes between two types of package maintainers: A Debian maintainer (DM) can upload only their own packages, whereas a Debian developer (DD) as a Debian member can upload any package.

Fedora

As soon as work starts on a new version of Fedora, the developers create a new GnuPG key [6] and use it to sign each RPM package published by the project. The key is used for the public test versions and for the final version.

Each architecture has its own key. In any case, the signatures are included in the metadata of the RPM package. Only some bleeding edge packages in the Rawhide distro do not have a signature.

It is the task of the package manager – dnf, rpm, and the corresponding GUI tools – to check the signatures [7]. Fedora stores the required public key in the /etc/pki/rpm-gpg directory after installing (Figure 3). Alternatively, users can find the public key online [8].

Figure 3: If a Fedora system does not have a public key for verification, the package manager (dnf in this case) prompts the system administrator to import one.

The Fedora team uses the Sigul [6] tool to manage and produce the keys. All hand-picked members of the project who need to sign packages (aka the release engineers [9]) also have access to the key.