I decided to rewrite the change proposal. I will then continue to state my opinions below. Given that I have written this myself, it can be said with certainty that I have actually *read,* and *interpreted* a significant portion of this change proposal.
--- This is a proposed change for Fedora Linux. As part of the changes process, proposals are announced to the public for comment. The proposal is then implemented when approved by the Fedora Engineering Steering Committee. == Summary== Introduce a new RPM macro, `%openpgverify`, for the purposes of replacing the currently used GnuPG cryptographic suite with Sequoia. GnuPG does not support post-quantum algorithms, and therefore, must be swapped out in anticipation of possible security breaches in the future. == Owner == * Name: [[User:jjelen| Jakub Jelen]] [[User:decathorpe | Fabio Valentini ]] * Email: [email protected], decathorpe AT gmail DOT com == Detailed Description == A group of former GnuPG engineers have forked the OpenPGP specification, then subsequently named it "LibrePGP," which is said to be incompatible with the former specification. These incompatibilities may cause some artifacts, which shall remain undisclosed (umm??). We have observed this situation, and believe for reasons that remain undisclosed, that the Fedora project should embrace the OpenPGP standard developed within the IETF, We have surmised that Sequoia-PGP implements this given standard adequately. It should also be known that Sequoia-PGP has already been used within RPM itself, in order to verify RPM signatures, and has been used since 2023. It has also been used within podman. --- I should first say that I agree with Neal Gompa: > 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. Switching around RPM macro names does seem to be an odd choice, considering that doing so requires more work than simply using a currently used and established macro name. Now, I agree that it it is always better to use more established standards, especially if they are adopted widely. It allows for better compatibility overall, and it may even help prevent compatibility (or interoperability) problems that cannot be anticipated. The most odd thing to note, is that on `https://librepgp.org/`, it is specifically stated that LibrePGP was forked specifically for the purpose of interop with *existing* implementations. This should be investigated further before this change is implemented; and I believe that the GnuPG team should be contacted specifically regarding the details of any potential interoperability issues, and to the specific reasons as to *why* this fork was made in the first place. Software security is very important to keep track of. If these kinds of changes are *not* investigated thoroughly, then unforeseen issues may occur. I believe that this investigation should be conducted as soon as possible. Sent with Proton Mail secure email. On Monday, July 20th, 2026 at 10:03, 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. > > > > -- > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > -- -- _______________________________________________ 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
