Hello Fedora Developers!
As part of the Fedora 45 Change "Sequoia openpgpverify" [1], rawhide has a
new macro, %openpgpverify, that verifies upstream source signatures with
Sequoia's sqv instead of GnuPG's gpgv. It takes the same options as
%gpgverify, so for most packages the switch is a rename plus one
BuildRequires.
I'm starting to send pull requests for this, ELN packages first [2]. This
is not a formal mass change; I'm writing so that you know what is coming,
and because some packages need their maintainer's attention before the
switch can work: their upstream keys or signatures are rejected by sqv.
Those are the ones where your help matters most.
What you can do now
-------------------
1. Find your packages in the per-maintainer list [3]. For each tested
package, proposals/<package>/ in the same repository has either the
exact patch and PR text, or an explanation of why it doesn't work yet.
2. If your package is in the "needs action" group (BUG.md), the signature
check fails with sqv while gpgv accepts it. The most common causes:
- The keyring in dist-git is outdated: upstream extended the key's
expiry or re-signed it after we copied it. Refreshing the keyring
from upstream fixes it.
- The upstream key's self-signatures use SHA-1. Upstream needs to
renew them (renewing the expiry does that) and publish the key.
- The release itself is signed with SHA-1 or with a DSA key. Upstream
needs to sign with a current key.
- The keyring contains an old v3 key (common in long-lived KEYS
files), which sqv can't read. Keeping only the current signing keys
fixes it.
I'll file bugs for these later, but it's quicker if you or upstream can
fix them earlier. Several upstream keys are shared by many packages,
so one fix often helps a whole family.
3. Convert the package yourself if you like: rename the macro, add
"BuildRequires: openpgpverify", drop "BuildRequires: gpgverify", and
run "fedpkg prep" or "fedpkg mockbuild". I check dist-git right before
opening a PR and skip packages that are already done. 21 packages were
converted by their maintainers since early October.
If a package must not be changed now, reply here or comment on the PR.
Why
---
sqv is a verifier built for exactly this job:
- No home directory, trust database or default keyring: only the keyring
named in the spec counts.
- It follows the system crypto policy and checks that the signing key was
valid and correctly bound to its certificate when the signature was
made.
- It supports the current OpenPGP standard (RFC 9580, including v6 keys
and signatures) and post-quantum (ML-DSA) signatures.
- It is the same OpenPGP implementation (Sequoia) that rpm already uses to
verify package signatures.
What a PR looks like
--------------------
-BuildRequires: gnupg2
+BuildRequires: openpgpverify
...
-%{gpgverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}'
--data='%{SOURCE0}'
+%{openpgpverify} --keyring='%{SOURCE2}' --signature='%{SOURCE1}'
--data='%{SOURCE0}'
- BuildRequires: openpgpverify is always added. %gpgverify works without
an explicit BuildRequires because redhat-rpm-config pulls in gpgverify;
nothing does that for openpgpverify.
- BuildRequires: gnupg2 is dropped only when the spec uses gpg for nothing
else and has no %check.
- The macro keeps its exact form (%{gpgverify} -> %{openpgpverify},
%gpgverify -k 2 ... -> %openpgpverify -k 2 ...). Note that
%openpgpverify --keyring=... without braces does not work.
- Specs without %autochangelog get a Release bump and a changelog entry.
Nothing changes in the binary packages, so no build is needed right
away.
- PRs target rawhide only. openpgpverify is also available in Fedora 43
and later, EPEL 9 and EPEL 10, so the change can be merged into those
branches as well if you like (not EPEL 8).
Each PR is tested: the current and the changed spec are both run through
%prep in a clean mock chroot without network access, and every call of
the verification tool is logged. A PR is only sent when the new spec makes
the same number of verification calls as the old one and all of them
pass.
Expired keys
------------
This came up in [4]: signatures made while the key was valid keep
verifying after the key expires. sqv checks validity at the time the
signature was made; we confirmed it on 14 packages whose keys have expired
since (dbus, logrotate, libmnl, ...). What fails is a keyring copy that is
older than the signature, and refreshing the keyring fixes that.
Numbers
-------
as of 2026-10-23
- 572 packages in rawhide still verify with %gpgverify or call gpg/gpgv
directly; 36 of them call gpg/gpgv directly and need hand-written PRs.
- 316 of them were tested so far (everything in ELN plus the smaller
half of the rest): 166 pass unchanged, 63 pass with a refreshed keyring
(waiting for review), 68 need upstream or maintainer action, and 16
call gpg directly.
Links
-----
[1] https://fedoraproject.org/wiki/Changes/Sequoia_openpgpverify
[2] https://github.com/fedora-eln/eln/issues/610
[3]
https://github.com/Jakuje/openpgpverify-migration/blob/main/announce/packages-by-maintainer.txt
[4] https://bugzilla.redhat.com/show_bug.cgi?id=2532553
The scripts, per-package state and templates are in
https://github.com/Jakuje/openpgpverify-migration. Tracker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2523619
The scripts and texts were prepared with the help of an AI assistant;
the commits carry an Assisted-by trailer. Every PR is tested as described
above and reviewed by me before it is opened.
Thanks,
Jakub Jelen
--
_______________________________________________
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
