When did we change from bottom posting to top posting?
Also: %{gpgverify} is the macro we use to verify signatures. Something
has to provide that macro, and something has to provide what that macro
needs.
If CentOS does not have gpgverify then that is where the problem needs be
solved. Abstracting things (in a macro and a single-purpose package) but
than "require"ing a concrete implementation and full suite from each
package was never right.
RHEL9 and RHEL10 are red herrings for any discussion about the present
and future of Fedora - simply because they are based on Fedora's past.
Cheers
Michael
Petr Menšík venit, vidit, dixit 2026-01-19 13:10:11:
> 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
--
_______________________________________________
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
