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
