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.


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.


Fedora Project community


  1. Allen Halsey

    The man page for rpm doesn’t show the


    Neither does the output of

    rpm --help


    $ cat /etc/redhat-release
    Fedora release 27 (Twenty Seven)

    $ rpm --version
    RPM version 4.14.1

    $ rpm --help | grep -F -- '-K' || echo "Not found"
    Not found
  2. B Russell

    Interesting that it uses -K to verify ONLY (does not do an install), but is undocumented in the man page or help pages.

    [packages]$ rpm -K xorg-x11-apps-7.7-18.fc27.x86_64.rpm

    xorg-x11-apps-7.7-18.fc27.x86_64.rpm: digests signatures OK

  3. B Russell

    Sorry for the multiple posts; I’m new at posting to Fedora Magazine. Anyway, -K can NOT be used with an install or upgrade:

    [packages]$ rpm -UvhK xorg-x11-apps-7.7-18.fc27.x86_64.rpm
    rpmkeys: –upgrade: unknown option

    [packages]$ rpm -iK xorg-x11-apps-7.7-18.fc27.x86_64.rpm
    rpmkeys: -i: unknown option

    Seems -K is ONLY for verifying and must be used on it’s own. Would be nice if the maintainers of rpm would update the man pages or help pages so we are not guessing.

    I’m very interested in that my current employer is going to be signing RPMS in the near future and the use of this option would help with creating build time unit tests.

  4. mac

    What is a

    "freeze" attack


Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions