F43 Change Proposal: Modular GnuPG packaging (self-contained)

Project Discussion Change Proposals
,
1

Modular GnuPG packaging

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

Currently GnuPG is packaged in a way that puts almost all tools and services into a single, monolithic RPM package. However, only few tools from the gnupg2 package are actually used by other tools and users. With this change, core tools and optional utilities are split off into separate packages.

:link: Owner

:link: Detailed Description

Currently GnuPG is packaged as a monolithic RPM that contains all tools and services (except the S/MIME support, which is in gnupg2-smime, but which is also pulled in by default).

This Change proposes to split the tools provided by the monolithic gnupg2 package into different subpackages, in part based on in how GnuPG 2.4 is packaged in debian:

  • gnupg2: gpg executable
  • gnupg2-dirmngr: certificate management service
  • gnupg2-g13: encrypted file system containers
  • gnupg2-gpgconf: core configuration utilities
  • gnupg2-gpg-agent: cryptographic agent
  • gnupg2-keyboxd: public key material service
  • gnupg2-scdaemon: SmartCard daemon
  • gnupg2-smime: S/MIME support
  • gnupg2-wks: Web Key Service (WKS) client and server
  • gnupg2-utils: non-essential utilities
  • gnupg2-verify: gpgv executable

By default, all new subpackages except those for WKS client/server (-wks) will get installed when gnupg2 is installed – with non-essential utilities in -utils being a weak dependency, like the existing S/MIME -smime package.

This results in fewer unused programs and / or services being installed and running, and would allow a more minimal install for scenarios where only gpg or gpgv are needed, for example, for signature verification during package builds.

Additionally, it allows swapping out the actual GnuPG implementation with the one based on Sequoia-PGP, which only depends on gpgconf and gpg-agent being present, but can otherwise function as a drop-in replacement for gpg and gpgv (even via the GPGME library).

Draft implementation of this change is available in pull request: PR#23: Split tools from monolithic gnupg2 package into subpackages - rpms/gnupg2 - src.fedoraproject.org

Test builds are available in COPR: decathorpe/gnupg2-split Copr

:link: Feedback

N/Y

:link: Benefit to Fedora

This change results in fewer unused executables and running services being installed by default, making more components optional. It also allows users to swap the gpg implementation on the system based on their needs.

:link: Scope

  • Proposal owners:

Packaging changes to the gnupg2 package to introduce new subpackages.

Adapt packages that require utilities that have moved to other subpackages of gnupg2 (TBD), file pull requests.

  • Other developers:

Review and merge pull requests.

  • Release engineering:

N/A (not a System-Wide Change)

  • Policies and guidelines:

N/A (not a System-Wide Change)

  • Trademark approval:

N/A

  • Alignment with the Fedora Strategy:

N/A

:link: Upgrade/compatibility impact

On upgrade to Fedora 43, some non-essential GnuPG utilities will no longer be available by default, and instead moved to the optional gnupg2-g13, gnupg2-utils, and gnupg2-wks packages.

Alternatively, these optional packages could get pulled in on upgrade, but not for “fresh” installs.

:link: How To Test

After upgrading to a Fedora version that has this change implemented, most gnupg2- subpackages should get installed, except for those noted in “Upgrade/compatibility impact” above. OpenPGP related functionality of the system should continue working as expected (note that this does not impact package management, which no longer uses GnuPG in any way).

:link: User Experience

This Change should not affect most users. On a default install, some non-essential GnuPG tools will no longer be included by default.

:link: Dependencies

N/A

:link: Contingency Plan

  • Contingency mechanism:

The Change Owners will revert the changes to the gnupg2 package and ensure an upgrade path for users who have already have the new subpackages installed on their systems.

  • Contingency deadline:

N/A (not a System Wide Change)

  • Blocks release?

N/A (not a System Wide Change)

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

The previously monolithic GnuPG package (gnupg2) was modularized, with several tools and non-essential utilities having been split into separate subpackages. The non-essential utilities (in gnupg2-utils) and some services that are unused on most systems are no longer installed by default.

Last edited by @amoloney 2025-04-16T14:20:26Z

Last edited by @amoloney 2025-04-16T14:20:26Z

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.