On Tue, Jul 21, 2026 at 5:51 PM Neal Gompa <[email protected]> wrote:
With my FESCo hat on, I don't see myself reasonably considering to > approve this change. The rationale is too weak. If you want to > introduce an *additional* interface, sure, whatever. But as it stands, > this juice is not worth the squeeze. > I agree that creating a different API and then switching to that is longer way, but I see it as a less painful one. If we would go with change of underlying macro it means we need to fix all packages by some time, otherwise they will fail to build. If the consensus about the name or the process will be different, I am open for discussion. If we would be replacing the gnupg from the gpgverify macro, we would need some backward compatibility and keep somehow the dependency on GnuPG for the cases using old/non-standard signatures, which would just lead to pulling both gnupg and sqv into the buildroot and I do not think we want that. Just over last couple of days, we have examples of packages that will have issues. Many (not that old) existing certs also use SHA1 in their binding signatures, which currently do not pass the stricter Sequoia checks. I believe these will have to be handled case by case with the upstreams. Even though there is quite an easy way to replace the SHA1 signature, it will require some efforts, that should not block others using the new tooling: https://www.redhat.com/en/blog/updating-gpg-keys-for-fedora-and-rhel Jakub
-- _______________________________________________ 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
