[Pkg-gnupg-commit] [gnupg2] 124/241: gpg: Fix cache consistency problem.

[Daniel Kahn Gillmor]

This is an automated email from the git hooks/post-receive script.

dkg pushed a commit to branch master
in repository gnupg2.

commit 7546e818791988c00b8635dab5b899265d8d9f42
Author: Neal H. Walfield <neal at g10code.com>
Date:   Wed Nov 11 18:26:53 2015 +0100

    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 <neal at g10code.com>
    Reported-by: NIIBE Yutaka <gniibe at fsij.org>
    
    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.
---
 g10/keyring.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/g10/keyring.c b/g10/keyring.c
index 81d2174..4e2145f 100644
--- a/g10/keyring.c
+++ b/g10/keyring.c
@@ -943,6 +943,7 @@ keyring_search (KEYRING_HANDLE hd, KEYDB_SEARCH_DESC *desc,
   int need_uid, need_words, need_keyid, need_fpr, any_skip;
   int pk_no, uid_no;
   int initial_skip;
+  int scanned_from_start;
   int use_offtbl;
   PKT_user_id *uid = NULL;
   PKT_public_key *pk = NULL;
@@ -1045,6 +1046,7 @@ keyring_search (KEYRING_HANDLE hd, KEYDB_SEARCH_DESC *desc,
   main_offset = 0;
   pk_no = uid_no = 0;
   initial_skip = 1; /* skip until we see the start of a keyblock */
+  scanned_from_start = iobuf_tell (hd->current.iobuf) == 0;
   while (!(rc=search_packet (hd->current.iobuf, &pkt, &offset, need_uid)))
     {
       byte afp[MAX_FINGERPRINT_LEN];
@@ -1080,7 +1082,7 @@ keyring_search (KEYRING_HANDLE hd, KEYDB_SEARCH_DESC *desc,
           if (need_keyid)
             keyid_from_pk (pk, aki);
 
-          if (use_offtbl && !kr_offtbl_ready)
+          if (use_offtbl && !kr_offtbl_ready && scanned_from_start)
             update_offset_hash_table (kr_offtbl, aki, main_offset);
         }
       else if (pkt.pkttype == PKT_USER_ID)
@@ -1168,7 +1170,7 @@ keyring_search (KEYRING_HANDLE hd, KEYDB_SEARCH_DESC *desc,
       hd->current.eof = 1;
       /* if we scanned all keyrings, we are sure that
        * all known key IDs are in our offtbl, mark that. */
-      if (use_offtbl && !kr_offtbl_ready)
+      if (use_offtbl && !kr_offtbl_ready && scanned_from_start)
         {
           KR_NAME kr;
 

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-gnupg/gnupg2.git