Fedora and GPG 2.5
The GNU Privacy Guard (GPG) project decided to break from the OpenPGP standard for email encryption in 2023, and instead adopted its own homegrown LibrePGP specification. The GPG 2.4 branch, the last one to adhere to OpenPGP, will be reaching the end of life in mid-2026. The Fedora project is currently having a discussion about how that affects the distribution, its users, and what to offer once 2.4 is no longer receiving updates.
gpg.fail
The Fedora discussion was prompted by the gpg.fail disclosures in late
December. Christian Stadelmann learned about the GPG flaws reported by the gpg.fail
researchers and noticed that Fedora's gnupg2 package had
not received any updates to fix those flaws. In fact, the package had
not been updated since July 2025. He asked
about this on the Fedora devel mailing list and pointed to
a bug that lists all the 2.5.x updates that have not been packaged
for Fedora. "Is it possible that gnupg is unmaintained? This would
pose a high security risk to the Fedora project.
"
The package was not unmaintained. Red Hat, which employs the GPG package's maintainer Jakub Jelen, has an annual shutdown at the end of the year during the holidays. Like many other Red Hat employees, Jelen was taking some time off. In addition, he explained on January 2, he was keeping the package on GPG's "oldstable" 2.4 branch deliberately. That was why the package had not seen updates in several months—its upstream had not pushed out any new 2.4 releases.
The 2.5 branch was originally an experimental branch that
implemented LibrePGP. Jelen noted that LibrePGP is not compatible with
anything else and would likely result in users shooting themselves in
the feet. "Updating to 2.5 would result in new users generating
incompatible LibrePGP keys, which I do not think is a good idea to do
now for all Fedora users.
" Since that is undesirable, he had been
staying on 2.4 and syncing with the FreePG repository that
contains a set
of patches that is maintained for downstream projects, such as
Debian and Fedora. The gnupg2 package for Fedora 43
includes a number of
patches from FreePG, though it does not include the patch
for LibrePGP format support.
Jelen said that he hoped to have a better solution by the time that
GPG 2.4 reaches the end of its life, "but I can not anticipate what it is
going to be
". Meanwhile, he also noted that he was pushing
out a package with the 2.4 fixes from the GPG project.
Michael Gruber pointed out that some of the fixes were available since October on the 2.4 branch (but not yet in a release). Jelen said that he was unaware of that, because he tracked the CVE database and there had not been CVEs issued. He said it made him question, again, whether Fedora should invest time and resources into an upstream that is not disclosing vulnerabilities clearly.
The communication around 2.5 has been somewhat muddy in general. Until
recently, the 2.5.x series was understood to be a development branch
and the next stable version of GPG would be 2.6. In June 2025, Koch
said in the announcement
for GPG 2.5.8 that the release was "another one in a
series of public testing releases leading to a new stable version
2.6
". The 2.5.9
release in July had similar language. Versions 2.5.10 and 2.5.11
did not have release announcements sent to the GPG announcement
list. In September, Koch announced
2.5.12 and said that the 2.5 series is fully supported and ready
for production use. He also sent out an announcement
for GPG 2.4.8 several months after it was actually released in
August 2025; that announcement noted that 2.4 would reach end of life
in June 2026. The news that 2.4's end of life was approaching was not
quite in the bottom of a locked filing cabinet in a disused lavatory,
but it would not be surprising if a number of users and packagers
missed the message all the same.
Alternatives
In the discussion that followed, Clemens Lang pointed
out that Red Hat was standardizing on the Sequoia project, and that Red Hat
Enterprise Linux (RHEL) 10 had dropped GPG's libgcrypt as a core
cryptography library. "RHEL 10 already contains RPM signing keys
that cannot be understood by GnuPG.
" Gruber said
that he was all for replacing GPG with something better, but
complained that Red Hat was choosing key types that would force
Sequoia adoption. He did not, however, offer a preferred replacement
for GPG.
Neal Gompa said
that Red Hat was not trying to drive Sequoia adoption with
incompatible key types; it had chosen post-quantum
cryptography (PQC) algorithms, and GPG simply does not support
PQC. Jelen agreed and said
that Red Hat was not forcing Sequoia adoption, and that any
implementation of the OpenPGP standard should do. "We just want to
stay on the 'standard' side".
Sequoia developer Neal H. Walfield said that there were two ways to replace GPG with Sequoia: convince application developers to switch, and finish the work-in-progress drop-in replacement (dubbed "Chameleon") for GPG that uses Sequoia.
The chameleon has the advantage that instead of forcing an application to switch to Sequoia, we give the user the freedom to choose what implementation they prefer. The disadvantage of the chameleon is that it has to be compatible with gpg, which means that we can't change the interface or the workflows. Further, since gpg's interface is quite complex with lots of subtle interactions, writing a perfect drop-in replacement will take a long time. So far we've implemented the functionality that some specific applications use. That has worked pretty well and I'd estimate that we have >90% coverage. But a lot more work is needed to cover the long tail of commands and their many options.
Petr Menšík brought up the %{gpgverify} macro used for Fedora RPM packaging. Fedora's packaging guidelines specify that packagers must use %{gpgverify} to perform verification of a source file's signature at the start of the build process for an RPM. Currently, that macro expands to an invocation of the gpgv signature tool. Gruber responded that the guidelines did not require that the macro call gpgv specifically, though; it could be changed to use Sequoia's sqv instead.
So far, no decision has been reached, though it would seem that the consensus is largely in favor of replacing GPG with Sequoia in instances where Fedora tooling requires signing and verification of OpenPGP signatures.
What to provide to users is still on the table. Arch Linux, Debian, Ubuntu, and other major distributions are still providing 2.4.x versions of GPG. Fedora tries to avoid deviating from upstream most of the time, but providing a version of GPG that does not implement the OpenPGP standard may not serve users well. The clock is ticking; the Fedora 44 release that is expected in April will likely ship with GPG 2.4.9, but a decision for Fedora 45 will need to be reached soon.
| Index entries for this article | |
|---|---|
| Security | GNU Privacy Guard (GPG) |