On Fri, 02 Jan 2026 11:43:43 +0100, Neal Gompa wrote: > On Fri, Jan 2, 2026 at 4:53 AM Jakub Jelen <[email protected]> wrote: > > > > 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. > > > > This is a huge problem. Right now, the critical path packages (the RPM > stack) use Sequoia-PGP, which doesn't support the incompatible > LibrePGP specification (it implements the IETF OpenPGP standard > instead) while GnuPG and RNP (both in Fedora and actively used) only > support LibrePGP and refuse to implement the IETF OpenPGP standard. > > People generally create and manage their PGP keys with GnuPG right > now, and we can't hold off on upgrading to GnuPG 2.5 forever if people > need to be using it as the primary method of interacting with PGP > keys. > > Fabio and I were discussing this in Matrix earlier this week, and I > think this is a problem that's only going to continue to get worse. > This situation might be bad enough that we need to consider discussing > with upstream (hi other Neal!) a true plan to be able to replace all > the GnuPG interfaces with Sequoia-PGP's Chameleon, including the GnuPG > Agent process.
There are two ways to replace the use of GnuPG. First, we can try and convince application developers to switch to Sequoia. I think this is a good idea, as the applications will be able to profit from Sequoia's APIs and design. But, there's a huge amount of both technical and non-technical work associated with this approach, and most likely a fair number of projects will refuse for various reasons, which is their prerogative. Second, we can write a drop-in replacement for gpg that interacts with the Sequoia ecosystem. That's what the chameleon is. https://packages.fedoraproject.org/pkgs/rust-sequoia-chameleon-gnupg/sequoia-chameleon-gnupg/ https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg 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. > So, what *should* we do, and what *can* we do? I don't want to decide what we should do. But, there are a few things we can do to promote the use of Sequoia. We can port our favorite applications to Sequoia. But, see above. We can try our favorite applications with the Chameleon and report (or even implement) any missing functionality. To use the chameleon on Fedora, see: https://sequoia-pgp.org/blog/2024/12/13/202412-sequoia-fedora/ Finally, as Neal points out, the Chameleon still relies on g10code's gpg-agent. Someone could help by replacing that component or helping with one of the other open issues: https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues :) Neal -- _______________________________________________ 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
