Page MenuHome GnuPG

Release GPGME 2.0.0
Open, NormalPublic

Description

Noteworthy changes in version 2.0.0 (2025-06-03) [C45/A0/R0]

  • The C++ bindings, the Qt bindings, and the Python bindings were split off of gpgme. They are now released separately. [T7262]
  • New function gpgme_op_random_bytes to get cryptographically strong random bytes from gpg. [T6694]
  • New function gpgme_op_random_value to get a cryptographically strong unsigned integer random value. [T6694]
  • New decrypt flag to skip the actual decryption so that information about the recipients can be retrieved.
  • New flag for key generate to mark a (sub)key as group owned.
  • If the key passed to gpgme_signers_add was retrieved with an exact pattern (fingerprint with '!' suffix), the requested subkey is used for signing. This reflects the behaviour of gpg but is a minor semantic change. [T3325]
  • The timestamp and expires fields in gpgme_subkey_t, gpgme_key_sig, and gpgme_new_signature_t are changed from signed long to unsigned long to better cope with 32bit time_t implementations. These fields should in reality never see an error value (-1).
  • Removed the gpgme_attr_t enums and their functions which were deprecated since 2003. [rMd54d6eaa64]
  • Removed the never implemented or announced GPGME_EXPORT_MODE_NOUID flags. [rMd54d6eaa64]
  • Removed the entire trustlist feature which worked anyway only for a short period in 2003. [T4834]

Interface changes relative to the 1.24 branch:

gpgme_op_random_bytes                   NEW.
gpgme_op_random_value                   NEW.
GPGME_RANDOM_MODE_NORMAL                NEW.
GPGME_RANDOM_MODE_ZBASE32               NEW.
GPGME_DECRYPT_LISTONLY                  NEW.
gpgme_subkey_t                          EXT: New field 'subkey_match'.
GPGME_CREATE_GROUP                      NEW.
gpgme_attr_t                            REMOVED.
gpgme_get_sig_ulong_attr                REMOVED.
gpgme_get_sig_string_attr               REMOVED.
gpgme_key_get_string_attr               REMOVED.
gpgme_key_get_ulong_attr                REMOVED.
gpgme_key_sig_get_string_attr           REMOVED.
gpgme_key_sig_get_ulong_attr            REMOVED.
gpgme_trust_item_get_string_attr        REMOVED.
gpgme_trust_item_get_int_attr           REMOVED.
GPGME_EXPORT_MODE_NOUID                 REMOVED.
GPGME_EVENT_NEXT_TRUSTITEM              REMOVED.
gpgme_trust_item_t                      REMOVED.
GpgmeTrustItem                          REMOVED.
gpgme_op_trustlist_start                REMOVED.
gpgme_op_trustlist_next                 REMOVED.
gpgme_op_trustlist_end                  REMOVED.
gpgme_trust_item_ref                    REMOVED.
gpgme_trust_item_unref                  REMOVED.
gpgme_trust_item_release                REMOVED.

(prev: T7440 next: T7817)

Event Timeline

werner triaged this task as Normal priority.Jun 3 2025, 1:09 PM
werner created this task.
werner created this object with edit policy "Administrators".

I'm wondering whether gpgme v1 will still be supported? Or it will be abandoned from now on.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

We won't fix or extend the gpgme 1.24 branch unless really needed for old projects. it is better to move on to the splitted stuff.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

Thanks for explaining. I’ll of course switch to GPGME 2.0. Since I only use the C API, the fact that the C++ and Qt bindings have been moved to separate repos doesn’t affect me—I can continue using the same interface. I’m asking on behalf of the Homebrew community since my macOS build depends on the Homebrew-maintained gpgme package. My suggestion is to add a “gpgme@2” formula while keeping “gpgme” (v1) intact, so active downstreams can opt into v2 without breaking older builds. The maintainers worry that, if v1 isn’t supported, we’d be forced to ship only v2. If it’s okay, I’d like to quote your explanation to reassure them and keep things moving.

You may refer: https://github.com/Homebrew/homebrew-core/pull/225591