Thank you for clarifications about the timeline. I was really not aware that this was already published earlier (while I cautiously keep an eye on GnuPG all the time) as I am focusing more on other topics recently and for vulnerabilities, I depend on the CVE database.
This makes me question again if we should really invest more time and resources into the upstream who is disclosing vulnerabilities in this way. Regarding the GnuPG funding, my understanding (at least according to the announcement in 2022, the GnuPG reached the state when it is already financially independent on donations and the development over the last years looked to me like "we have a contract from X for PQC in GnuPG, but we do not have time to discuss this on IETF so we do it our way". Its likely shortcut, there was likely many intermediate steps and hard decisions, but this is the outcome. Two incompatible standards. https://lists.gnupg.org/pipermail/gnupg-devel/2022-January/035021.html Anyway, by now, all Fedora versions (testing) should have an update of gnupg 2.4.9. For the question what we can/should do to avoid the explosion/difference from what GnuPG introduces might be the use of FreePG mentioned previously. It is a shared initiative of downstream maintainers that try to avoid the LibrePGP parts also in the GnuPG 2.5 branches. But I did not have time to dig into that deeper to be confident to rebase to freepg 2.5 releases, which is likely inevitable and likely the best course of action for everyone: https://gitlab.com/freepg/gnupg If anyone has some strong opinions on this, please let me know on or off the list. Jakub On Fri, Jan 2, 2026 at 11:38 AM Michael J Gruber <[email protected]> wrote: > Hi Jakub > > Thanks for the update and the "state of the PG union address" :) > > The following is no complaint but an attempt to steer a black vs white > discussion towards a more than 2 color spectrum. > > To be fair, some (all?) of the fixes in 2.4.9 were available in October > on the master branch, including POC code in the commit messages. While > the bug, fix and POC were reported responsibly, publishing the POC code > in the commit message (by gnupg maintainers) could have made two groups > of people aware of the severity: > > - black hats exploiting the bug > - downstream maintainers cherry-picking the fixes > > In an ideal world, upstream would not have released POCs but a timely > 2.4.9 back in early November. In the real world, this happened the other > way round, and it's no wonder people draw conclusions from this about > gnupg maintenance both upstream and downstream in Fedora, such as: > > - upstream considers 2.5 stable (rather than hotfixing 2.4) > - Fedora carries 2.4 > - Fedora did not backport available patches (from 2.5 to 2.4) > > All of these conclusions are factually true. > > Now, there are reasons both for upstream's and downstream's decisions. > In particular, thanks to Jakub for being so clear and considerate about 2.5 > which could have lead us into a different kind of mess! > > It appears that Gnupg is not an easy upstream to follow currently, > purely in the technical sense: "our" current branch is "their" > under-maintained legacy branch, their current branch may break our use > cases. > This at a time where the PG ecosystem is at a difficult branch point, > gnupg being maybe underfunded/understaffed, teams breaking up and > forking (libre, sequoia...). > > Some fun facts and an idea: > > - Other implementations such as sequoia are affected by some of the > bugs, too. > > - The demo at 39C3 downloads a fake Fedora 43 iso/sig and verifies it > successfully (including sha256sum) against the official Fedora key. At > least that's what it looks like on the CLI with an unpatched gnupg. > [No, they're not blaming it on Fedora.] > > - We limit other cryptographic software. Can we limit gpg 2.5 in a way > which would avoid creating incompatible keys (unless --expert or such > is used), thus opening a path to carry "upstream's stable version"? > > Michael > > Jakub Jelen venit, vidit, dixit 2026-01-02 10:50:35: > > Hello all! > > Thank you for the message and interest in the GnuPG! What was said about > > the state is mostly true (not the thing about being unmaintained, but > about > > sticking on the "oldstable" release). And thanks Adam for heads up. > > > > For the CVEs, I just merged a rebase to 2.4.9 (thanks @Clemens Lang > > <[email protected]> for the PR!) and its building: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=140639106 (other > Fedora > > versions will follow) > > > > To answer separate questions, the CVEs were published on 29th December > and > > upstream release one day after. Unfortunately I was not around the > computer > > to fix this faster. No update for 6 months really does not mean that > > package is unmaintained. There was just no reason to update the package. > > > > We are keeping the Fedora version of GnuPG on the 2.4 branch as said > above > > intentionally. The 2.5 started as mostly experiment implementing the > > LibrePGP standard, which is not compatible with anything else (IETF's > > OpenPGP) and would likely result in users shooting themselves into their > > feet. I also synced couple of patches over the last years with FreePG > > project, which is trying to maintain the version 2.4 in a compatible > manner: > > > > https://gitlab.com/freepg/gnupg > > > > 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. I > > am hoping we will have some better solution by the time the 2.4 version > > will reach EOL, but I can not anticipate what it is going to be. > > > > Best, > > Jakub > > > > On Tue, Dec 30, 2025 at 7:50 PM Adam Williamson < > [email protected]> > > wrote: > > > > > On Tue, 2025-12-30 at 11:49 +0000, Christian Stadelmann wrote: > > > > Thanks for your response! I'm sorry I might have been a bit > impatient. > > > Some of the bugs were fixed upstream, but I am aware that we cannot > expect > > > a maintainer to track upstream so closely that they would get notified > on > > > these upstream fixes. > > > > > > In case you're not aware, Red Hat has a company shutdown every year > > > from Dec 25 through Jan 2 (more or less), meaning basically everyone > > > who works at RH is off work during that time. Of course there's cover > > > for critical functions, but generally you can't expect an RH-employed > > > maintainer to be doing 'routine' stuff like upstream monitoring during > > > that timeframe. I'm pretty sure the gnupg maintainers *do* usually > > > monitor upstream things like this, but during this particular > > > timeframe, it's different. > > > -- > > > Adam Williamson (he/him/his) > > > Fedora QA > > > Fedora Chat: @adamwill:fedora.im | Mastodon: @[email protected] > > > https://www.happyassassin.net > > > > > > > > > > > > -- > > > _______________________________________________ > > > devel mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > > https://lists.fedoraproject.org/archives/list/[email protected] > > > Do not reply to spam, report it: > > > https://pagure.io/fedora-infrastructure/new_issue > > > > >
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
