keyring search regression in master
Neal H. Walfield
neal at walfield.org
Wed Nov 11 11:22:22 CET 2015
At Wed, 11 Nov 2015 15:57:28 +0900,
NIIBE Yutaka wrote:
> On 2015-11-11 at 12:11 +0900, NIIBE Yutaka wrote:
> > # List with LONG-ID doesn't work
> > $ gpg2 --homedir=/tmp/gpghome --list-key 79A79093084239CF
> > gpg: error reading key: No public key
> I think I located the problem, but I don't know how to fix.
> It was introduced by the function check_user_ids. It searches once,
> and then, in the line 2198, it searches again.
FWIW, this is not a bug. The second search (which is just a
continuation of the previous search) makes sure that the search
returns a single result, i.e., that the key specification is not
ambiguous relative to the DB's contents.
> Here, packets up to
> the next PKT_PUBLIC_KEY will be skipped and subkeys are not registered
> to the hash table. Next time keyring_search will be called, the call
> to lookup_offset_hash_table will fail (as the subkey is not
> registered) and returns -1.
It sounds like the bug is in the keyring code and this patch simply
uncovered it. (I did a quick test and I don't think the problem
occurs when using a keybox.)
More information about the Gnupg-devel