On Mon, 12 Jan 2026, Neal H. Walfield via devel wrote:
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.
Thanks for doing this. I do believe gnupg 2.5 should not replace the
existing gnupg 2.4 package. If someone wants it as standaling gnupgp25,
that seems fine with me.
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.
Once people want post-quantum keys, the break between OpenPGP and GnuPG
will be finalized and remain incompatible moving forward. Unless GnuPG
will start supporting OpenPGP v6 keys. Which I assume they wouldn't do
for a long time or else they risk momentum on their own incompatible key
format and crypto operations.
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.
Unfortunately, people will need to start using other tools for openpgp
keys. As stated above, as soon as you introduce GnuPG 2.5 as replacement
package for GnuPG 2.4, you introduce a fundamental breakage and RFC 9580
(openpgp v6 keys with PQC) won't be supported and keys generated by
gnupg won't be supported by any other openpgp library/tools.
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.
This is not a bad approach, but it should not be the only one. But
making application developers aware of the non-standard operating
mode of gnupg would be useful to alert them they will need to make
changes to their applications.
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.
Telling people to convert to "sop" is probably a good idea.
https://www.openpgp.org/about/sop/
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
Yes, gpg-agent is an important part to get done too, because a lot of
people use this in their git workflow as well.
Paul
--
_______________________________________________
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://forge.fedoraproject.org/infra/tickets/issues/new
