--weak-digest SHA1 causes significant slowdown in --check-trustdb (2.1.10)

[Neal H. Walfield]

Hi Daniel,

On Wed, 06 Jan 2016 10:44:24 +0100,
Daniel Kahn Gillmor wrote:
> and, also interestingly, i note that --weak-digest SHA1 --check-trustdb
> thinks it can reach one fewer key with --no-sig-cache  is set :/
> 
> ==> gpg2 --weak-digest SHA1 --check-trustdb <==
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: Note: signatures using the SHA1 algorithm are rejected
> gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: depth: 1  valid:   9  signed: 283  trust: 9-, 0q, 0n, 0m, 0f, 0u
> gpg: next trustdb check due at 2016-01-15
> 
> 
> ==> gpg2 --no-sig-cache --weak-digest SHA1 --check-trustdb <==
> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
> gpg: Note: signatures using the SHA1 algorithm are rejected
> gpg: Note: signatures using the MD5 algorithm are rejected
> gpg: depth: 0  valid:   1  signed:   9  trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: depth: 1  valid:   9  signed: 284  trust: 9-, 0q, 0n, 0m, 0f, 0u
> gpg: next trustdb check due at 2016-01-15
> 
> sorry for just reporting weird corner cases here without helping to fix
> them.

Ouch!  I appreciate you not only reporting this bug, but providing a
reproducible test case!

Unfortunately, the caches in gpg are often not completely transparent.
Finding the corner cases is hard and, thus far, consistent with "don't
change a working system," we've been conservative in fixing their
semantics.  I think this provides strong evidence that we really need
to nail down the caches so that they are transparent.

Thanks!

:) Neal