Page MenuHome GnuPG

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


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.

Event Timeline

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
PASS: initial.test
Running t-config...
Running t-version...
Running t-keylist...
Running t-keylist-secret...
FAIL: t-json
stopping gpg-agent 
PASS: final.test
1 of 3 tests failed
Please report to
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.

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 triaged this task as Normal priority.

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.

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.

aheinecke changed the task status from Open to Testing.May 8 2020, 10:40 AM

I have opened T4939 to add the keylist mode with keygrip.