I think it would help for a start, if we allowed verification of
signatures by something different than gnupg2. It MUST be done by
%{gpgverify} macro, meaning using sequia-sqv is not allowed. Can we
change that, please?
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures
I have done that in dnsmasq for a test. It is nice, but parameters of
sqv are a bit different.
https://src.fedoraproject.org/rpms/dnsmasq/pull-request/24
I think sqv should be officially allowed, unless there exist well
specified reason why not.
Cheers,
Petr
On 12/01/2026 16:28, 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.
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
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
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
