F45 Change Proposal: Sequoia opengpgverify (self-contained)

Project Discussion Change Proposals
,
1

Sequoia %opengpgverify

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.

Wiki
Announced

:link: Summary

Introduce a rpm macro %openpgpverify and update packages to use it instead of existing gnupg specific %gpgverify. 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.

:link: Owner

:link: 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 RPM signatures since 2023, as well as in podman. RPM also supports signing RPMs using Sequoia tools since version 6.0 so adjusting the rpm macros is natural next step.

:link: Feedback

:link: 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.

:link: Scope

  • Proposal owners:
 * Create a new %openpgpverify macro using sqv CLI
 * Verify it works with existing artifacts in Fedora, fix/workaround/report possible issues.
 * Change %gpgverify rpm macro in existing spec files to use %openpgpverify 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: #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: ?

:link: 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.

:link: Early Testing (Optional)

Verify all packages that use %gpgverify macro work with %openpgpverify.

Do you require ‘QA Blueprint’ support? Y/N

:link: 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?

:link: User Experience

This change should not affect user experience.

:link: Dependencies

  • rust-sequoia-sqv
  • gpgverify
  • other packages using gpgverify

:link: 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), Yes/No

:link: Documentation

Fedora packaging guidelines need to be updated to reflect this change.

N/A (not a System Wide Change)

:link: 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.

Last edited by @amoloney 2026-07-20T14:04:18Z

Last edited by @amoloney 2026-07-20T14:04:18Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Do you have a list of affected packages?

Are you planning on filing pull requests for these? or mass changing them yourself? or just asking maintainers to do so? (I’ll point to Making sure you're not a bot! )

In any case, I like this change.

4

I am generally in favor, but…

I have this recollection (which may be wrong) that sqv will not verify if the signers key is expired. This may result in some packages no longer passing the openpgpverify that do currently pass with gpgverify. A quick look at the man pages for sqv do not show an obvious way to bypass that expiration check.

5

Not yet. This is mostly about setting up the tools (macro) and do PoC it works in most of the cases.

This is not yet decided. I would like to do the mass change (I will certainly need to do mass test somehow), but I agree that not every package maintainer might be happy about that so likely it will be some mix of doing the changes, asking people to do that and PRs, I think.

Thank you! This is a good point! I think the --time option can override that, but I will have to double-check this.

6

As far as I know, signatures should be considered “valid” if the key was valid at the time when the signature was made, even if the key expired between making that signature and $now.

7

Somebody else mentioned this in another forum, but I have to concur: why not just replace %gpgverify with a sequoia-based wrapper rather than requiring changes to so many packages to make the switch?

8

Two reasons:

  • It allows switching packages over on an opt-in basis, after verifying that the changes work. Changing the existing macro would apply to all packages immediately, and likely break in some cases. I also don’t think it’s clear yet whether the macro will even have the exact same API as the old one.
  • Fixing the name. gpg / GnuPG is a specific implementation (that is now no longer following the IETF standard), whereas openpgp is the correct name of the format / protocol.
4 Likes
9

I would agree, that is the way it should work, but I have a package for which that assumption does not seem to hold.

FWIW, I plan to update the package signing keys RSN for those packages, so I will no longer care, but I suspect that there will be some set of packages where the package maintainers have not done the equivalent homework for this change proposal (and to refer to others comments, is why a global replacement to sequoia-sqv is probably going to cause issues for a few packages; how many, I do not know, but zero is clearly not the correct number).

1 Like
10

I think the proposal needs to be rewritten in neutral, purely technical language.

The whole gpg/openpgp/sequoia situation is poisoned enough already, and there is no need to add to this by using formulations like “decided to …”, “might allow getting forged artifacts” etc. Avoid anything related to the IETF wg controversity, any FUD either way. Otherwise this just looks like the one-sided sq fanboying that one sees too often, and creates (deserved) backlash like the one on the devel-list.

Just work with the facts: current standard, current implementation used in rpm already etc.

It would also help if some of the analysis (“needs to be evaluated”) would have need done already, at least partially.

11

Maybe the verificiation time should be set to $SOURCE_DATE_EPOCH?

12

I really tried, but sounds like its probably not enough. Feel free to propose specific changes and I would be happy to incorporate them. I tried to drop/rewrite the two places you mentioned in your comment.

This is work in progress. I posted already some notes from this to fedora-devel:

More info will come once I will have more information and time to toy with that. I also updated this information on the wiki for now.

13

The change here sounds fine, but if it’s purely a question of changes to build tooling, I’m not sure i see the point of tying it to a particular Fedora release. And I definitely don’t see why it would appear in the Release Notes.

In fact I’m not sure I really see it as a Fedora Linux change at all. It’s a dist-git / koji / bodhi / packagers / infra change. One that doesn’t need to constrain, or be constrained by, the distro release timetable.

We’re going to want this in place on the build systems for the release in question, before the release in question, so that it can be used to create the release in question['s packages], right? So, these changes have to be released well before the release.

(Yes, the overuse of “release” in that paragraph was intentional.)

Also, once this is ready on the backend, shouldn’t it be made available for older releases as well? Sometimes package updates need to be pushed to older releases, which I generally do like this:

git checkout rawhide
# (make changes to foo.spec,
# presumably that includes switching to %openpgpverify)
git commit foo.spec
git push
fedpkg build

git checkout f44
git merge rawhide
git push
fedpkg build

git checkout f43
git merge rawhide
git push
fedpkg build

So I’d prefer that the %openpgpverify tooling not break in older release branches, once it’s enabled in any release branch.

14

This is planned, as I think I mentioned previously on the mailing list. Though it might make sense to mention it explicitly in the proposal. Thank you.

15

This seems to fit the description here just fine though Making sure you're not a bot!

In general, Changes are for coordination of development effort and for communication (both internally and externally).

(emphasis mine)

I tend to rebase spec changes for some of my packages too, for non-backward-breaking updates … perhaps the recommended approach should be to do

%if 0%{?fedora} >= 45
%opengpgverify ...
%else
%gpgverify ...
%endif

16

This change proposal has now been submitted to FESCo with ticket [#3660](Making sure you're not a bot!) for voting.

To find out more, please visit our [Changes Policy](Making sure you're not a bot!) documentation.