When did it change from Requires: gnupg2 to Requires: gpgverify by the
way? The issue I have with that is we do not have that tiny thing in RHEL.
I try to keep the most recent rawhide branch buildable in RHEL too,
without any modifications. ELN branch is exactly building rawhide branch
like RHEL. Because we do not have gpgverify in RHEL, any package with
BuildRequires: gpgverify will fail to build on RHEL10, CentOS 10 and
even in eln branch, afaik.
This seems like major issue in new proposed way. I fail to see a good
reason for it. gnupg2 provides everything on RHEL9 and RHEL10 and worked
well enough. This creates a regression compared to previous state. It
works on epel branches, but not on centos only repositories.
https://gitlab.com/redhat/centos-stream/rpms/gpgverify
On 16/01/2026 17:12, Michael J Gruber wrote:
Petr Menšík venit, vidit, dixit 2026-01-16 16:55:25:
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.
Do you envisage different packages using different verification tools? I
don't think that flies well.
I do not read the guidelines as requiring that gpgverify needs to be
*that* gpgverify, only:
```
The verification MUST be done with the macro %{gpgverify}, which expands into a
command whose parameters shall be the pathnames of the keyring, the signature
and the signed file. BuildRequires: gpgverify is necessary for the verification
to work.
```
I read it like MUST used in RFCs,
https://datatracker.ietf.org/doc/html/rfc2119#section-1. Not optional.
SHOULD would have to be used there instead.
This has certainly changed. All my packages with PGP signature still
have BuildRequires: gnupg2 with rpm -E %gpgverify pointing to
/usr/lib/rpm/redhat/gpgverify. This is a change that needs modification
in my opinion.
I think redhat-rpm-config should provide %gpgverify_requires gpgverify
on Fedora. It might be provided also on RHEL10 and RHEL9 package, where
it would still contain %gpgverify_requires gnupg2. Kind of similar to
%systemd_requires or %pyproject_buildrequires.
If we use macros for build dependency, we could insert also
%gpgverify_requires (sequoia-sqv or gnupg2). That would work also on
RHEL systems without Fedora EPEL repositories enabled. It should be
simple to detect presence of at least one of such tools in shell script
and verify it.
What I do not understand is, why is not gpgverify in normal
/usr/bin/gpgverify? It should have also man page perhaps?
sqv's purpose is not being a drop-in replacement. That purpose is served
by `gpgv-sq` from `sequoia-chameleon-gnupg`. `gpgverify` from the same
named package wraps `gpgv` and could simply wrap `gpgv-sq` instead, or
`sqv`. That way no package needs to change, assuming existing signatures
are "v4 or below".
We do not have to use drop-in replacement of gnugp2. What we have
already in gpgverify is a shell wrapper, transforming used parameters. I
see no reason why the same wrapper cannot support also verification
using sqv tool. The only difference is in --data= parameter. sqv also
prefers to specify --signature-file, we have that parameter parsed. I am
sure that can be fixed by the shell script itself.
Alternatively, the gpgverify macro could call `sqv` directly, keeping
the macro call signature as is.
I mean, if we use sq for rpm signatures we can use it for source tarball
checks by default, can't we?
Cheers
Michael
--
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
