[pkg-gnupg-maint] Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Mar 5 15:21:37 GMT 2021


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20210305/02c75115/attachment.sig>


More information about the pkg-gnupg-maint mailing list