Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1
On Fri 2021-03-05 10:21:37 -0500, Daniel Kahn Gillmor wrote: > 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. So i've dropped the patch in debian experimental, but i haven't done anything for the version currently in unstable/testing. I'd be curious to hear other people's thoughts about whether it's right to make the change before the freeze for Debian bullseye as well. Arguments for trying to make the change for bullseye are described above. arguments for not making the change for bullseye include: - this seems to introduce gratuitous breakage for some tools that use gpgme, expect the keygrip, but don't know about GPGME_KEYLIST_MODE_WITH_KEYGRIP - it seems to be trying to support gpg1, which we are otherwise already trying to figure out how to phase out I'm unsure of the right tradeoff here, but i welcome input on it. --dkg signature.asc Description: PGP signature
Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1
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
