Page MenuHome GnuPG

keyring: cache consistency problem
Open, LowPublic


At the end of keyring.c:keyring_update_keyblock, we update the cache:

  key_present_hash_update_from_kb (key_present_hash, kb);

On irc, Werner confirmed that the new keyblock is not necessarily a superset of
the original keyblock:

<neal> werner: When keyring_insert_keyblock is called, can we assume that if

the keyblock is being replaced, that the set of keys/subkeys will be a superset
of the original keys/subkeys?

  <werner> neal: No. Packets may have been removed.

If a subkey was removed (say A), then the cache will be inconsistent.
Concretely, if we look up A, then the cache will indicate that it is present in
the keyring, even though it isn't. Fortuitously, the practical implications are
minimal. This is because if we look up A in keyring_search, the cache will say
it is present, then we scan the keyring to find the offset. Since it is not
found, we return ENOENT. (Only if the cache says that a keyid is not present do
we we skip the scan.)

The cache is thus only useful when we lookup a lot of keys that are not present
in the keyring. I'm curious when this occurs in practice. I currently can't
think of any such situations and as such would recommend removing this cache.

Event Timeline