Fixed in b2572b0c.

Hi Justus,

Thanks for your response. In further testing, I was able to trigger the "FAIL:
gpgtar.scm" during a make check for 2.1.13 (actually "FAIL: gpgtar.test" for
2.1.13 since it's pre-tiny-scheme). In particular, it's vanilla 2.1.13 + your
fix in 8f79c31b. So I think what may be going on is that 8f79c31b didn't
actually fully resolve that problem after all since I've now seen it occur, with
that commit included, in 2.1.13, and in 2.1.14, and in HEAD.

Tbere were two cases where a more specific error was emitted:

In one run, I saw this:

((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet
(ctb=2d)
gpgtar: gpg: [don't know]: invalid packet (ctb=2a)
gpgtar: error running
'/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

and in another run I saw this

Checking gpgtar with signature 
((/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-0U4bUB/archive) failed: gpgtar: gpg: Fatal: zlib inflate problem:
invalid block type
gpgtar: error running
'/private/tmp/gnupg21-20160726-74591-maikty/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm

It's also worth noting that I've only been able to trigger the problem on
Jenkins during CI, not locally, so I don't know if the lack of TTY is relevant
or something like that.

I will do the ssh check you requested.

Thanks for letting us know. Unfortunately, we do not test on MacOS yet, but we are working
on that.

I have neither experience with debugging on MacOS, nor do I have access to such a machine.
I'm afraid you are on your own for now.

The ssh test is new, so we need to figure out why it does not work. Please do

  make -C tests/openpgp check TESTS="setup.scm ssh.scm" verbose=2

This lets us see what ssh-add prints to stderr. It might be related to the version of
OpenSSH shipped with the OS.

That is not a bad commit, that is Werner evolving our software. pygpgme is unmaintained since

2013. My guess is that it cannot cope with the new status code being emitted by GnuPG.

I ran the testsuite myself, and I can reproduce the issue, among many other failures: 24 if I'm
using the GnuPG components from Debian/unstable, 9 if I am using more recent components.

One of them is test_encrypt_to_signonly, which tries to encrypt a mail to a key only usable for
signing, and expects a general error, which all recent versions of GPGME return in this case, but
this was a bug, fixed in GPGME master, which returns the correct error.

Updating pygpgme is out of scope for us. If you merely need any binding, consider using the pyme3
bindings that we merged into GPGME proper, and will release with 1.7. You can also find it on
pypi, it requires GPGME 1.6.x to build.

The way I see it is that the pygpgme bindings and its test suite are way too unmaintained and the
test suite too noisy to demonstrate a bug in GnuPG or GPGME. Feel free to reopen this bug if you
have compelling evidence that we broke something, preferably a small test case not using pygpgme.

I have now tested HEAD at revision 4ba11251aff578394000bf480f47160f0879c763 and
2.1.13 (including this patch
https://raw.githubusercontent.com/Homebrew/formula-patches/7b2211b/gnupg21/spawned_child_8f79c31b.diff)

The results are

1. The "FAIL: gpgtar.scm" does *not* affect the patched 2.1.13, so it appears to

be a regression.

2. The "FAIL: gpgtar.scm" is not fixed in HEAD at

4ba11251aff578394000bf480f47160f0879c763.

3. There is a further regression in HEAD at

4ba11251aff578394000bf480f47160f0879c763, which seems not to be found in 2.1.14:

PASS: default-key.scm
Checking key export 
    > D74C5F22 C40FDECF ECABF51D <  
PASS: export.scm
Importing ssh keys... 
    > dsa key not added 
FAIL: ssh.scm
Checking passphrase cache (issue2015)... 
PASS: T2015.scm
Checking import statistics (issue2346)... 
PASS: T2346.scm

Here's the relevant snippet:

PASS: tofu.scm
Checking gpgtar without encryption 
Checking gpgtar without encryption with nicer actions 
Checking gpgtar with asymmetric encryption 
Checking gpgtar with asymmetric encryption and signature 
Checking gpgtar with signature 
((/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/tools/gpgtar --gpg
/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg --gpg-args
--no-permission-warning --always-trust --tar-args --directory=. --decrypt
/tmp/gpgscm-PgAlmV/archive) failed: gpgtar: gpg: [don't know]: invalid packet
(ctb=2d)
gpgtar: gpg: [don't know]: invalid packet (ctb=2a)
gpgtar: error running
'/private/tmp/gnupg21-20160725-43964-l18ixl/gnupg-2.1.14/g10/gpg': exit status 2
) 
FAIL: gpgtar.scm
Importing public key. 
Checking that the most recent, valid signing subkey is used by default 
    > 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 <  
Checking that we can select a specific signing key 
    > 8BC90111 F5F77B83 1EA97479 <  
PASS: use-exact-key.scm
Importing public key.

Yeah, unfortunately this is still happening even with my attempt to fix it with
deparallelization, so that's not the issue.

macOS 10.9 build bot has failed in the same place again.

The document you cite also states that UID/UAT lines only use field 10.

Also, neither UID nor UAT packets encode an expiration date [0], the way an UID/UAT can expire
is that the self-signature expires [1].

0: https://tools.ietf.org/html/rfc4880#section-5.11
1: https://tools.ietf.org/html/rfc4880#section-5.2.3.3

I do no longer agree with your first problem. Key expiration is different from signature
expiration, the way to quickly generate a key that expires in one year is:

    $ g10/gpg --quick-gen-key quick_test - - 1y

I guess one could argue that if one specifies --default-cert-expire=X when adding an uid, that
the self-signature for the new uid should expire. But to be honest, I doubt that this matches
user expectations.

What would be the use case really? I know that I'll lose access to that mail address in X years
and hence want my uid to expire then.

Fixed in 4ba11251.

How did you create the key? I tried to reproduce it, and my numbers are even funnier:

% gpg2 --list-packets key2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!

off=0 ctb=95 tag=5 hlen=3 plen=919

:secret key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2046 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1016 bits]
checksum: 4197
keyid: 576109131A46786C

off=922 ctb=b4 tag=13 hlen=2 plen=29

:user ID packet: "Test Keyyy <test@example.org>"

off=953 ctb=89 tag=2 hlen=3 plen=311

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x13
digest algo 8, begin of digest 79 38
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 9 10 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2045 bits]

off=1267 ctb=9d tag=7 hlen=3 plen=920

:secret sub key packet:

version 4, algo 1, created 1262304006, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
skey[2]: [2047 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1024 bits]
checksum: 4233
keyid: 2D1354FDD1343C83

off=2190 ctb=89 tag=2 hlen=3 plen=287

:signature packet: algo 1, keyid 576109131A46786C

version 4, created 1262304006, md5len 0, sigclass 0x18
digest algo 8, begin of digest 49 47
hashed subpkt 2 len 4 (sig created 2010-01-01)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 576109131A46786C)
data: [2047 bits]

% GNUPGHOME=$(mktemp -d) gpg2 --import key2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.vt2HmFYk11/pubring.kbx' created
gpg: /tmp/tmp.vt2HmFYk11/trustdb.gpg: trustdb created
gpg: key 576109131A46786C: public key "Test Keyyy <test@example.org>" imported
gpg: key 576109131A46786C: secret key imported
gpg: Total number processed: 3
gpg: imported: 1
gpg: secret keys read: 3
gpg: secret keys imported: 2

I'd say 'Total number processed' and 'secret keys read' is off by one even if one counts the
subkeys.

Ah, I misunderstood your problem. In the future, please paste all program interactions in one chunk
in the right order. We did merge some changes related to exporting of secret keys, so it may very
well be solved by that.

Thanks for caring :)

ff71521d9698c7c5df94831a1398e948213af433 is the first bad commit
commit ff71521d9698c7c5df94831a1398e948213af433
Author: Werner Koch <wk@gnupg.org>
Date: Fri May 13 16:24:59 2016 +0200

    gpg: Emit new status line KEY_CONSIDERED.
    
    * common/status.h (STATUS_KEY_CONSIDERED): New.
    * g10/getkey.c: Include status.h.
    (LOOKUP_NOT_SELECTED, LOOKUP_ALL_SUBKEYS_EXPIRED): New.
    (finish_lookup): Add arg R_FLAGS.  Count expired and revoked keys and
    set flag.  Check a requested usage before checking for expiraion or
    revocation.
    (print_status_key_considered): New.
    (lookup): Print new status.
    
    Signed-off-by: Werner Koch <wk@gnupg.org>

:040000 040000 33853092f4376553defb24e39a31bdcbc13c51d2
7da8083e3f39b2fabfe0c3beab0b9f43a2a2cc32 M common
:040000 040000 468469de2419e59efddd718b7b24d5a8cead3005
d2c77b1e1bbab29cd506b29dc359d44c841dbc99 M doc
:040000 040000 044148a54b854a31a0f6ad6605a50a57cc46dfcd
e229f5d63dc27377a7fa1d50ff512a040a389f1f M g10

D378: 864_0001-configure.ac-restore-user-CFLAGS-before-checking-fun.patch

Update patch to cover libraries search (e.g. iconv).

I think the problem is that your key export fails, because you pointed
--homedir at the (presumably) empty directory "%tmp%\_tempKeyring".

The export did not use any filter and tried to export a key as can be seen in
Msg8313 "error receiving key from agent"
The import itself also stated no errors as it can be seen in T2355 (dranft on May 12 2016, 03:00 PM / Roundup), but this
imported secret key cannot be used (or exported) anymore.
Also important: This is no longer reproducible in 2.1.14 (which might be enough
to set the bug to fixed)

I don't believe this demonstrates a bug.

I think the problem is that your key export fails, because you pointed --homedir at the (presumably)
empty directory "%tmp%\_tempKeyring". This leads to the not very helpful error message about the
eof. If the export were successful, gpg would have written the key to stdout.

For reference, here is what I tried. First GNUPGHOME points to a home with the key I want to export:

    $ echo $GNUPGHOME
    /tmp/tmp.T7I4M9RIc3
    $ g10/gpg --list-keys alpha
    gpg: please do a --check-trustdb
    pub   dsa1024 1999-03-08 [SCA]
          A0FF4590BB6122EDEF6E3C542D727CC768697734
    uid           [ unknown] Alfa Test (demo key) <alfa@example.net>
    uid           [ unknown] Alpha Test (demo key) <alpha@example.net>
    uid           [ unknown] Alice (demo key)
    sub   elg1024 1999-03-08 [E]

You need some kind of pinentry program, because you may be asked for the current passphrase or an
export passphrase:

    $ cat $GNUPGHOME/gpg-agent.conf
    pinentry-program /usr/bin/pinentry-x11

Now export the key:

    $ g10/gpg --export-secret-keys alpha >/tmp/alpha.gpg

Now I create an empty home, and import the key in batch mode:

    $ export GNUPGHOME=$(mktemp -d)
    $ g10/gpg --batch --import /tmp/alpha.gpg
    gpg: keybox '/tmp/tmp.bL2caQmZri/pubring.kbx' created
    gpg: /tmp/tmp.bL2caQmZri/trustdb.gpg: trustdb created
    gpg: key 2D727CC768697734: public key "Alfa Test (demo key) <alfa@example.net>" imported
    gpg: key 2D727CC768697734: secret key imported
    gpg: Total number processed: 3
    gpg:               imported: 1
    gpg:       secret keys read: 3
    gpg:   secret keys imported: 2

Could you please check if that works for you?

Fixed in d9839c9d.

On 2016-07-19, Justus Winter via BTS wrote:

Ok, I pushed a fix related to this problem 45bb9a2a, this had the amusing effect of
reversing the behavior:

% rm -f $GNUPGHOME/tofu.db ; ( g10/gpg --verify --status-fd=1 /tmp/testmsg
)2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key)
<alpha@example.net>"%0Ain the past 0~seconds.
[GNUPG:] TOFU_STATS 2 1 0 auto 0 0
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the
past 0~seconds.

The difference stems from tofu_register setting already_verified to 0 for the first
uid, and to 1 for the second. In the former case, show_statistics is asked to ignore
the current message.

I guess the intention was to handle the very first message differently, but now we
are handling the first *uid* upon receiving the first message differently instead.
I'm not sure how to proceed, hence reassigning to Neal.

This is a GnuPG problem:

teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
teythoon@europa ~/repos/g10/gpgme/obj/tests (git)-[master] % rm $GNUPGHOME/tofu.db && ( gpg2 --verify --with-
colons --status-fd=1 /tmp/testmsg && gpg2 --verify --with-colons --status-fd=1 /tmp/testmsg && sleep 1 && gpg2 -
-verify --with-colons --status-fd=1 /tmp/testmsg )2>/dev/null | grep TOFU_STATS
[GNUPG:] TOFU_STATS 1 0 0 auto
[GNUPG:] TOFU_STATS_LONG Verified 0 messages signed by "Alfa Test (demo key) <alfa@example.net>".
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 1 0 0 none
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alfa Test (demo key) <alfa@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alpha Test (demo key) <alpha@example.net>"%0Ain the past
1~second.
[GNUPG:] TOFU_STATS 2 1 0 auto 1 1
[GNUPG:] TOFU_STATS_LONG Verified 1 message signed by "Alice (demo key)"%0Ain the past 1~second.

Looks like other folks are experiencing same issues:
https://lists.gnupg.org/pipermail/gnupg-users/2016-March/055421.html

My problems are resolved. I have not encountered a problem since your last
fixes. Although I sometimes have to reenter pin so I think the errors still
occur occassionally but gnupg recovers.

Thanks.

It is handled in scdaemon (not in g10/keyedit.c).

When the keysize is different, it changes key attribute automatically.
For 2.1, it was fixed by f10b427d0e2be333776fee2df8150145da36e587 on 2015-09-07
which is in 2.1.8.

This has nothing to do with faking time one way or another.

You are reporting two problems. In the future, please create two issues.

I agree with your first problem, even though there is additional syntax for specifying the
expiration date with --quick-gen-key. This is easy to fix.

Your second problem is less clear. First of all, your command line makes no sense. --
default-sig-expire only affects signatures over data. Furthermore, user ids do not
expire, merely the (self-)signatures may do so. Do you want that?

I do consider it a bug, at least because we did not signal an error to ssh-add.
Fortunately, this was easy to fix.

Fixed in 270f7f7b.

Yes, that is very likely the same bug. Feel free to reopen this report if yuo
can still reproduce it, in which case a backtrace would be very handy.

Fixed in 28fd0ab.

I agree, these are problems we should address, they might be the symptoms of a
race somewhere. I bet they are in GnuPG though.

Fixed in 774dbffe.

I don't have time to look at this immediately, but it looks related to Werner's
recent change to the tofu db code.

So the key listing is enclosed in tofu_{begin,end}_batch_update:

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

at ../../g10/gpg.c:4153

#0 tofu_begin_batch_update () at ../../g10/tofu.c:389
#1 0x0000000000452515 in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:137

#2 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

Then an transaction is started on the email and key db:

#0 begin_transaction (db=0x733bc0, only_batch=0) at ../../g10/tofu.c:278
#1 0x0000000000497365 in record_binding (dbs=0x71cf40,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", policy=TOFU_POLICY_AUTO, 
show_old=0) at ../../g10/tofu.c:1202

#2 0x0000000000498e36 in get_trust (dbs=0x71cf40, pk=0x71a8a0,

fingerprint=0x71c980 "362D3527F53AAD1971AAFDE658859975EE37CF96", 
email=0x71cf60 "testing (insecure!)", 
user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2182

#3 0x000000000049a44d in tofu_get_validity (ctrl=0x715870, pk=0x71a8a0,

user_id=0x71ab30 "Testing (insecure!)", may_ask=0) at ../../g10/tofu.c:2946

#4 0x000000000048f4b2 in tdb_get_validity_core (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, main_pk=0x71a8a0, sig=0x0, may_ask=0)
at ../../g10/trustdb.c:1074

#5 0x000000000048cd9d in get_validity (ctrl=0x715870, pk=0x71a8a0,

uid=0x71aac0, sig=0x0, may_ask=0) at ../../g10/trust.c:338

#6 0x000000000048caeb in uid_trust_string_fixed (ctrl=0x715870, key=0x71a8a0,

uid=0x71aac0) at ../../g10/trust.c:154

#7 0x00000000004544bc in list_keyblock_print (ctrl=0x715870,

keyblock=0x71a9c0, secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:950

#8 0x00000000004567aa in list_keyblock (ctrl=0x715870, keyblock=0x71a9c0,
---Type <return> to continue, or q <return> to quit---

secret=0, has_secret=0, fpr=0, listctx=0x7fffffffd560)
at ../../g10/keylist.c:1604

#9 0x00000000004533bc in list_all (ctrl=0x715870, secret=0, mark_secret=0)

at ../../g10/keylist.c:556

#10 0x000000000045254e in public_key_list (ctrl=0x715870, list=0x0,

locate_mode=0) at ../../g10/keylist.c:143

#11 0x000000000040e496 in main (argc=0, argv=0x7fffffffdc08)

    at ../../g10/gpg.c:4153

... and later ended, but since !! batch_update, it is not actually committed.

Now when tofu_end_batch_update is called and batch_update drops to zero, it iterates
over db_cache and commits all transactions using end_transaction, but db_cache is
empty. This is actually not that surprising, because the only place I see db_cache
being populated is in tofu_closedbs, a few lines after the failing assertion.

Fixed in f4742493.

D369: 860_0001-Core-Add-file_size-support-to-gpgme_data.patch

Since Kleopatra is using data callbacks the total is always 0 so I can't use the
way to calculate percent.

Previously kleopatra used the filesize as total value. This does not work if
total is always 0 and the progress switches based on the current file size. E.g
for a large file the prgress decreases after 1024*1024 bytes have been processed.

I could probably add some weird "if gnupg > 2.1.14 and the file size is >
1024*1024 and the progress is < 1024*1024 expect it to be bytes and otherwise
expect it to be kilobytes." But this is not nice to use API.

My attached patch solves this by giving data callback users the opportunity to
provide GnuPG with the information how much input size it can expect. This makes
total / current workable from the start and everything is fine.

But as we jabbered about you do not like this patch :'-(

Problem not resolved for me as I think the weird handling currently imposed by
GnuPG is definitely not "Easy"

For the T2238, it was backported in effect (not intentional, though).

1.4: ca1fc59
2.0: 1c15136

The attached patch was lost, but is available at
https://gist.githubusercontent.com/fornwall/751acc6fbe9eb8e703c60c222a2dba33/raw/ece6b6
8fe0346b2039be6ba3323e5e29e25685ef/configure.ac.patch

I see. We use system() in the random test to re-execute itself. This involves
the shell and thus the problem. Need to uses fork/exec or CreateProcess calls
for that test. I guess this needs to wait until we have moved that to code to
libgpg-error as our portability layer.

This is still a problem on OS X 10.11.5. OS X's System Integrity Protection
"feature" is causing that test failure. If S.I.P is disabled there's no problem.

A similar-looking test failure happens in perl
(https://rt.perl.org/Public/Bug/Display.html?id=126706). Perhaps the diagnosis is
the same here.

The only messing I want to do is to a) not tamper with the user's homedir and b)
not leak any files after I'm done.

For a) a homedir sounds fine. But then I can't use the user's secret keys to
sign other keys.
For b) I tried to rely on existing infrastructure to make my life easier. I
expected it to work because it did for the primary keyring. But GnuPG behaves
inconsistently regarding the primary keyring and the trustdb file. Even more
so, because running gpg a second time just appears to work. That makes gpg not
intuitive to use, I think.

And this is, I guess, the main issue I'm seeing.

You may want to test 1.7.2 instead.

1.7.2 with the fix has been released

2.4.3 has been released and I assume that this works now. Feel free to re-open
if it is not the case.

Please do not mess around with file managed by GnuPG. It is not your business ;-).

I'd strongly suggest to use a temporary home directory and use --import and
--import-ownertrust to add keys.

You should better use --recv-key if you already know the fingerprint. Anyway,
this is a regression and will be fixed for 2.1.14 with commit 0342369. Thanks.