gpgme's json test fails with gpg 2.2.19
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	dkg
	Jan 23 2020, 11:40 PM

Description

Since the upgrade to gpg 2.2.19, gpgme's tests/json/t-json fails.

It appears to fail because of changes to the json output when asking for secret keys Alpha and Bravo.

With gpg 2.2.19 installed, the test appears to fail for all versions of gpgme, from the current git master, all the way back to gpgme commit 88b7221eb737a3102ec61ea385990b7ea7ef2b30, when the json test was originally introduced.

I did a bit of digging into the cause of this, and it looks like there are two relevant differences:

earlier versions of gpg were emitting a # in field 15 for keys that it didn't have any secret key for; this caused gpgme-json to emit '"secret": true' incorrectly. 2.2.19 appears to have corrected that misbehavior, so gpgme-json is now emitting '"secret": false', as it should.

I propose to fix this by correcting the gpgme-json test to reflect reality.
earlier versions of gpg were emitting keygrips for keys that it didn't have any secret key for, but 2.2.19 only emits keygrips for all keys (secret and non-secret alike) when deliberately supplied with --with-keygrip.

I propose to fix this by having gpgme always send --with-keygrip when it is listing keys. This doesn't appear to break any existing tests.

I'll submit a patch series shortly.

Revisions and Commits

rM GPGME
	rM004fdf61c8b9 core: Make sure the keygrip is available in WITH_SECRET mode.
	rM5c0d1c7f76c9 tests, json: Do not check for keygrip of pubkeys
	rMcff600f1f65a Do not test for a bug in older GnuPG versions
	rMf2aeb2563ba2 tests/json: Bravo key does not have secret key material
	rMc4cf527ea227 gpg: Send --with-keygrip when listing keys

Related Objects

Mentioned In: T7003: 2.2 gpg-agent doesn't allow KEYINFO when restricted (was: gpgme-1.23.2 test failure (t-json))
T4854: gpgme 1.13.1: test suite is failing
T4996: Release GPGME 1.14.0
T4939: GPGME: Add KEYLIST_MODE_WITH_KEYGRIP
T4861: GPGme 1.13.1 fails at t-json
Mentioned Here: T4939: GPGME: Add KEYLIST_MODE_WITH_KEYGRIP
T4061: gnupg: --with-colons --with-secret returns wrong results if specific keys are queried
rM88b7221eb737: tests,json: Add missing files and chunking test

Event Timeline

dkg created this task.Jan 23 2020, 11:40 PM

For easier reference or searchability, the test error looks like this:

make[1]: Entering directory '/home/dkg/src/gpgme/build/tests/json'
make  check-TESTS
make[2]: Entering directory '/home/dkg/src/gpgme/build/tests/json'
starting gpg-agent..
gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent|--debug-quick-random'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
OK
PASS: initial.test
Running t-config...
 success
Running t-version...
 success
Running t-keylist...
 success
Running t-keylist-secret...
 failed
FAIL: t-json
stopping gpg-agent 
PASS: final.test
=======================================
1 of 3 tests failed
Please report to https://bugs.gnupg.org
=======================================
make[2]: *** [Makefile:618: check-TESTS] Error 1
make[2]: Leaving directory '/home/dkg/src/gpgme/build/tests/json'
make[1]: *** [Makefile:744: check-am] Error 2
make[1]: Leaving directory '/home/dkg/src/gpgme/build/tests/json'
make: *** [Makefile:746: check] Error 2

The dkg/fix-4820 branch now has these two fixes.

in particular, c4cf527ea227edb468a84bf9b8ce996807bd6992 and f2aeb2563ba2f55eea7f52041e52062fdc839a64

dkg added commits: rMc4cf527ea227: gpg: Send --with-keygrip when listing keys, rMf2aeb2563ba2: tests/json: Bravo key does not have secret key material.Jan 24 2020, 12:31 AM

Thanks! I would merge your commits but I'll like to talk to werner tomorrow about the always adding "--with-keygrip" I also think its useful but it might have expensive internal side effects that I am not aware of.

thanks for looking at this, @aheinecke ! if you or @werner know of any internal side effects where this does matter, it would be great to add a test that documents them.

• aheinecke added a commit: rMcff600f1f65a: Do not test for a bug in older GnuPG versions.Jan 29 2020, 11:06 AM

Well thanks for reporting it ;-)

I have just pushed a different fix for the first failure with the "secret: true" by removing the check there altogether instead of checking for the value false to avoid breakage when run with older GnuPG versions.

Regarding the --with-keygrip part of the patches, werner is looking into it. We want to understand why it changed in GnuPG and then decide if we should revert to the old behavior.

I would like to understand why this changed. T4061 might be relevant here. This has been fixed after the 2.2.19 release.

The idea is that we compute a keygrip if we are listing secret key,s want to have info whether a secret key is also available or if --with_keygrip has been given. For secret key listings the keygrip computation is free for all other we try to avoid the roundtrip to Libgcrypt. OTOH, we will anyway store the keygrip as meta-data in the future, thus --with-keygrip could be made the default - at least in master.

kopfuss added a subscriber: kopfuss.Feb 27 2020, 9:44 PM

dkg mentioned this in T4861: GPGme 1.13.1 fails at t-json.Feb 27 2020, 11:08 PM

• aheinecke merged a task: T4861: GPGme 1.13.1 fails at t-json.Feb 28 2020, 11:26 AM

Any progress on this one?

To end the failures I have modified the test, that needed to be done anyway since different versions of GnuPG behave differently.

I've discussed this with Werner and we don't think always adding --with-keygrip is a good solution as this requires additional calculations in GnuPG which will slow down all keylistings.

IMO a proper solution here is to add a new keylist mode flag "WITH_KEYGRIP" to make this explicit for users of GPGME.