gpgme's json test fails with gpg 2.2.19
Open, NormalPublic

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.

dkg created this task.Jan 23 2020, 11:40 PM
dkg added a comment.Jan 23 2020, 11:57 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
dkg added a comment.Jan 24 2020, 12:23 AM

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.

dkg added a subscriber: werner.Mon, Jan 27, 6:08 PM

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 assigned this task to werner.Wed, Jan 29, 11:06 AM
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.