aboutsummaryrefslogtreecommitdiffstats
path: root/dirmngr/dirmngr-client.c
diff options
context:
space:
mode:
authorNeal H. Walfield <[email protected]>2015-11-11 17:26:53 +0000
committerNeal H. Walfield <[email protected]>2015-11-11 17:32:16 +0000
commit7546e818791988c00b8635dab5b899265d8d9f42 (patch)
tree0a875d623befa243aeb33c43fb3b3d8f729c76ab /dirmngr/dirmngr-client.c
parentgpg: Default to the the PGP trust model. (diff)
downloadgnupg-7546e818791988c00b8635dab5b899265d8d9f42.tar.gz
gnupg-7546e818791988c00b8635dab5b899265d8d9f42.zip
gpg: Fix cache consistency problem.
g10/keyring.c (keyring_search): Only mark the cache as completely filled if we start the scan from the beginning of the keyring. -- Signed-off-by: Neal H. Walfield <[email protected]> Reported-by: NIIBE Yutaka <[email protected]> A new feature (e8c53fc) turned up a bug whereby checking if a search term matches multiple keys in the keyring causes the cache to be inconsistent. When we look for a key on the keyring, we iterate over each of the keyblocks starting with the keyblock following the last result. For each keyblock, we iterate over the public key and any subkeys. As we iterate over each key, we first insert it into the cache and then check if the key matches. If so, we are done. In pseudo code: for (i = last_result + 1; i < num_records; i ++) keyblock = get_keyblock (i) for (j = 1; j < len(keyblock); j ++) key = keyblock[j] update_cache (key) if (compare (key, search_terms)) return ok cache_filled = true return ENOFOUND When we look for the next match, we start with the following keyblock. The result is that any subkeys following the key that matched are not added to the cache (in other words, when a keyblock matches, the inner loop did not necessarily complete and the subsequent search doesn't resume it). This patch includes a straightforward fix: only indicate the cache as complete if we started the scan from the beginning of the keyring and really didn't find anything.
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions