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