[pkg-gnupg-maint] Bug#833640: Bug#833640: gpg --recv-keys: does something for 5 minutes without any information

[Ansgar Burchardt]

Daniel Kahn Gillmor writes:
> On Thu 2016-08-11 03:25:00 -0400, Ansgar Burchardt wrote:
>> Ansgar Burchardt writes:
>>> I imported two keys using `gpg --recv-keys 0x... 0x...` (this is gpg2
>>> here) this morning. After reporting that both keys had been retrieved
>>> successfully, gpg decided to spend some minutes doing something: I
>>> think checking the trustdb.
>
> this sounds frustrating! It sounds to me like it is likely checking the
> trustdb that is taking this much time.  do you have a large keyring?

It has gotten fairly large (34 MB), but I don't think any regular
operation should take 5 minutes even with that. If I ask gpg to check
all signatures, fine, but just importing a key shouldn't cause gpg to
recheck *all* signatures if that takes this long: checking the
signatures of the newly imported key is enough.

> one thing you can do as a workaround is to put "no-auto-check-trustdb"
> in ~/.gnupg/gpg.conf
>
> If you do that, you'll get an alert when gpg thinks the trustdb needs
> updating, but you can decide when you want to schedule that lengthy
> process.   (when you do, you can just run "gpg --check-trustdb")

I think I'll try this.

>>> However there was no indication that gpg was supposed to still be
>>> doing anything. It would be nice if there was an informational message
>>> on the terminal for long-term operations: at least a note that this
>>> might take a while, ideally some sort of progress indication.
>>
>> The same happens when importing a single new signature:
>>
>> +---
>> | $ gpg --import < ${something}
>> | gpg: key [...] 3 new signatures
>> | gpg: Total number processed: 1
>> | gpg:         new signatures: 3
>> | gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
>> | gpg: depth: 0  valid:   1  signed: 140  trust: 0-, 0q, 0n, 0m, 0f, 1u
>> | gpg: depth: 1  valid: 140  signed: 150  trust: 1-, 13q, 35n, 77m, 14f, 0u
>> | gpg: depth: 2  valid:  57  signed:  80  trust: 9-, 5q, 9n, 31m, 3f, 0u
>> | gpg: depth: 3  valid:   9  signed:  17  trust: 2-, 0q, 3n, 4m, 0f, 0u
>> | gpg: depth: 4  valid:   3  signed:   5  trust: 0-, 0q, 0n, 3m, 0f, 0u
>> | gpg: next trustdb check due at 2016-09-07
>> +---
>>
>> With gpg(2) taking quite a while:
>>
>> +---
>> | 11077 ?        RLs    4:49 gpg --import
>> +---
>
> your initial report was against gnupg2 -- 2.1.11-7, which shipped as
> /usr/bin/gpg2.  i see you using "gpg" here -- are you using the newer
> version of gnupg (in experimental) that ships as /usr/bin/gpg ?  or is
> "gpg" aliased to "gpg2" ?  or should this bug report be moved to the
> gnupg1 package?

It is gpg2: I have a gpg -> /usr/bin/gpg2 symlink in ~/bin to get some
more programs to use gpg2.

>> I guess I should no longer refresh the keyring or sign other people's
>> keys.  Who knows how long it will take for importing more than one new
>> signature or key. ;)
>
> :P -- rather, we should get this bug diagnosed and fixed :)
>
> a few diagnostic reports that would help me understand the state of your
> keyring would be to show me the output of:
>
> a)    time gpg --with-colons --list-keys | grep -c ^pub:

+---
| % time gpg --with-colons --list-keys | grep -c '^pub:'
| 305
| gpg --with-colons --list-keys  1.82s user 0.02s system 99% cpu 1.833 total
| grep --color=auto -c '^pub:'  0.00s user 0.00s system 0% cpu 1.833 total
+---

> b)    ls -la ~/.gnupg/pubring.*

+---
| -rw------- 1 [user] [group] 35331533 Aug 11 09:13 [~]/.gnupg/pubring.gpg
| -rw------- 1 [user] [group] 35331533 Aug 11 09:13 [~]/.gnupg/pubring.gpg~
+---

> c)    gpg --export-ownertrust | grep -v '^#' | cut -f2 -d: | sort | uniq -c

See private mail.

Ansgar