On Mon, Jul 20, 2026 at 10:03 AM Aoife Moloney via devel-announce < [email protected]> wrote: > > Wiki - https://fedoraproject.org/wiki/Changes/Sequoia_opengpgverify > Discussion thread - > https://discussion.fedoraproject.org/t/f45-change-proposal-sequoia-opengpgverify-self-contained/197231 > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > == Summary == > Introduce a rpm macro <code>%openpgpverify</code> and update packages > to use it instead of existing gnupg specific <code>%gpgverify</code>. > The new macro will use standard OpenPGP implementation from Sequoia > instead of GnuPG by default to provide support for Post Quantum > Cryptography defined in the OpenPGP WG. This is part of gradual > switching from GnuPG dependency. > > > == Owner == > * Name: [[User:jjelen| Jakub Jelen]] [[User:decathorpe | Fabio Valentini ]] > * Email: [email protected], decathorpe AT gmail DOT com > > > == Detailed Description == > The GnuPG decided to fork the OpenPGP specification as LibrePGP to > develop incompatible standard in 2023. Since then, the GnuPG 2.5.* > versions (not present in Fedora) can create artifacts incompatible > with current OpenPGP standard. We are observing the situation and the > we believe Fedora project should embrace the OpenPGP standard > developed within the IETF, which involves gradually switching from the > GnuPG to other implementations where possible. > > We identified Sequoia-PGP as a good candidate as it implements the > standard OpenPGP (including the RFC 9980 standardizing PQC). The > Sequoia-PGP is already used as part of RPM to verify > [https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ RPM signatures] > since 2023, as well as in > [https://src.fedoraproject.org/rpms/rust-podman-sequoia podman]. RPM > also supports [ https://github.com/rpm-software-management/rpm/blob/master/docs/man/rpmsign.1.scd#examples > signing RPMs using Sequoia tools] since version 6.0 so adjusting the > rpm macros is natural next step. > > == Feedback == > > > == Benefit to Fedora == > * Prevent vendor-lock-in in GnuPG ecosystem. > * Follow IETF standardization > * Improve security by providing developers with ability to use Post > Quantum Cryptography to sign their artifacts. > * Integrate better with the rest of the operating system by following > system wide crypto policies. > > == Scope == > * Proposal owners: > * Create a new <code>%openpgpverify</code> macro using sqv CLI > * Verify it works with existing artifacts in Fedora, > fix/workaround/report possible issues. > * Change <code>%gpgverify</code> rpm macro in existing spec files to > use <code>%openpgpverify</code> where possible with proven packager or > PRs > > * Other developers: Respond to possible issues/PRs in cases where this > will not work out of the box. > > * Release engineering: > [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue > number] > > * Policies and guidelines: The Packaging Guidelines should be updated > to make use %openpgpverify macro by default. > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with the Fedora Strategy: N/A > > > == Upgrade/compatibility impact == > No upgrade impact -- this involves just build system and development. > > Compatibility needs to be evaluated. There should not be any existing > librePGP artifacts, but there might be some old GnuPG keys that will > not pass stricter Sequoia checks. Identifying them will help increase > security of the supply chain as insecure keys might allow getting > forged artifacts to Fedora. > > > > == Early Testing (Optional) == > Verify all packages that use <code>%gpgverify</code> macro work with > <code>%openpgpverify</code>. > > > == How To Test == > * Have a dist git of a package with upstream tarball signed with GPG key > * Update gpgverify BuildRequires to openpgpverify > * Update %gpgverify macro to %openpgpverify > * Verify the local package build works for you with `fedpkg local` or > `fedpkg mockbuild` > > If not, review the log, key(ring) and report potential issues to the > upstream developer or Sequoia developers. Do they use SHA1 in their > certificate? Do they use small RSA key that could be broken by Quantum > Computer in close future? > > > > == User Experience == > This change should not affect user experience. > > > > == Dependencies == > * rust-sequoia-sqv > * gpgverify > * other packages using gpgverify > > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > > == Documentation == > Fedora packaging guidelines need to be updated to reflect this change. > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures > > N/A (not a System Wide Change) > > == Release Notes == > Fedora is using Sequoia to by default to verify upstream tarball > signatures during the build time. This allows upstreams to sign their > artifacts using Quantum Resistant algorithms defined in the latest > OpenPGP RFC 9980. >
Sorry, I don't think this makes sense. Why %openpgpverify instead of just changing the implementation under %gpgverify? Changing packages like this for something that is already abstracting the tools seems weird. If you want to rename it, %pgpverify would be fine, but it's still seems unnecessary. 真実はいつも一つ！/ Always, there's only one truth!
-- _______________________________________________ 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
