Package: src:gpgme1.0 Version: 1.13.1-2 Control: affects -1 gpg1 In gpgme 1.13.1-2, I added debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch in an attempt to fix https://dev.gnupg.org/T4820.
Upstream's alternative fix was instead to not test the output that breaks with older, known-buggy GnuPG versions (see upstream commits cff600f1f65a2164ab25ff2b039cba008776ce62 and 5c0d1c7f76c95bad8bce4ad3bafd121ec5101d3c), and to add an extra flag (GPGME_KEYLIST_MODE_WITH_KEYGRIP) that users of GPGME need to supply if they want to ensure that the keygrip field of the gpgme_subkey_t object is populated (see c8048bf8eb988f22b20215197f4739bedafc4264) I now see in the OpenPGP test interoperability test suite (https://tests.sequoia-pgp.org) a terse report that "GPGME uses --with-keygrip unconditionally, breaking GnuPG 1.4". Indeed, gpg1 does not appear to support the --with-keygrip flag at all. It's not clear to me that the proposed upstream API is particularly easy to use, but maybe it's better to drop the remaining patch and align with upstream expectations, because: - the test suite already has dropped coverage of the relevant parts, so the test suite won't fail. - in T4820, upstream appears concerned about additional compute cost of generating keygrips (though i haven't seen any attempt to characterize the total compute cost) - alignment with upstream is good in itself One possible consequence of doing this this is that gpgme-dependent tools that expect the keygrip field to be populated (as it indeed was by default when gpgme was backed with older versions of gpg) may break until they learn to apply GPGME_KEYLIST_MODE_WITH_KEYGRIP (which in turn would oblige them to depend on gpgme >= 1.14.0). Another alternative would be to make debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch conditional on the version -- only do that when the backend is known to be version 2.2.x or higher. I'm leaning toward just dropping the patch. --dkg
signature.asc
Description: PGP signature