How Fedora Secures Package Delivery

Eariler this year, PackageCloud published a blog post on “attacks against GPG signed APT repositories”. Currently, Fedora uses several ways to ensure that packages from the Fedora repositories are delivered to you securely. This article provides a high-level insight in to how the Fedora Project secures our update delivery. Note, however, that the following analysis only applies to the default Fedora Project repositories as shipped with Fedora.

Signed packages

All RPM packages shipped by the Fedora Project are GPG-signed. Installing packages with DNF (or YUM) from a repository where gpgcheck=1 is set — which is true for all repositories in a default Fedora installation — will fully verify the signatures on the packages. If you install a package outside of a repository (manually downloading it for example), the signature will not be verified automatically. However, it can be manually verified against the current set of imported RPM GPG signing keys with rpm -K <filename.rpm>.

As such, just signing a package prevents against that package being modified or an entirely different package being provided, but not against “freeze” attacks or malicious repository data.

Signed repositories

The Fedora Project does not sign our package repositories (yet), even though this has been requested a lot of times. One of the main reasons for this is that DNF/YUM repodata has no “ValidUntil” or sortalike attribute. Additionally, librepo — which DNF uses to download and verify repodata– regards expired GPG signatures as fully valid. This means that there is no way at all to mark repository data as valid for a limited amount of time.

As such, while it can protect against modification of the repository data, it does not protect against attackers (or outdated mirrors) shipping ancient repositories with known-vulnerable software.

Metalink

So, how are Fedora users protected? The Fedora Project uses a data format called “Metalink” to provide YUM/DNF not only with a list of mirrors that they can download all our software from, but also a list of reasonably fresh repomd.xml checksums to expect. repomd.xml contains the checksums of all other referred files. Consequently, if a mirror is serving outdated or modified repodata, DNF/YUM will detect this, and just skip over this mirror. All our repository configurations are set to request the metalink over TLS from the Fedora Project servers.

Now, an important part here is the “reasonably fresh” part. Repositories are regenerated every day, and the checksums are sent for at most the last 3 days. This ensures that mirrors that are slightly outdated are not immediately regarded as invalid.

However, when a significant security issue is announced and we have repositories that include fixes for this issue, there is an “Emergency” button. This tell the servers to immediately regard every older repomd.xml checksum as outdated.

When this button is pressed, every mirror that does not have the very latest repository data will be regarded as outdated.  This ensures that Fedora users get the security patches as soon as possible. However, for a period of time only the master mirrors are trusted until other mirrors sync their data. This solution was chosen over delaying getting important fixes out to our users and making them vulnerable to attackers in the meantime.

So, as long as a Fedora install’s repository configurations remain unchanged, you will be guaranteed (save for any issues in the code surrounding DNF/YUM) to get fresh repositories, and get critical security patches as soon as they are available.