GnuPG 2.1 Migration fails badly with (weird) PGP2 key in pubring
Closed, ResolvedPublic

Description

I have a user that had a very old and very large public keyring.
He encountered errors (gpg: keydb_get_keyblock failed: Value not found) during
migration to gnupg 2.1 and was unable afterwards to decrypt things.

Through some testing / bisecting (and realizing he had a weird key in his pubring):
pub 999R/F88341D9 1994-11-08

I came down with this boiled down script to reproduce the problem (using gpg
1.4.16 and gpg2 2.1.7-beta3):

  export GNUPGHOME=$(mktemp -d)
  gpg --keyserver hkp://keys.gnupg.net --recv-key F88341D9
  echo Key-Type: RSA >> $GNUPGHOME/test
  echo Key-Length: 1024 >> $GNUPGHOME/test
  echo Passphrase: 123 >> $GNUPGHOME/test
  echo Name-Real: PGP2 is annoying >> $GNUPGHOME/test
  echo Name-Email: bugs@g10code.com >> $GNUPGHOME/test
  gpg --gen-key --batch < $GNUPGHOME/test
  gpg2 -K

Result:

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/tmp/tmp.ucwuHgbgNt/secring.gpg' to gpg-agent
gpg: keydb_get_keyblock failed: Value not found
gpg: key 805110EB: secret key imported
gpg: migration succeeded
gpg: checking the trustdb
gpg: keyring_get_keyblock failed: Unknown system error
gpg: failed to rebuild keyring cache: Unknown system error
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: keydb_search_first failed: Legacy key
gpg: validate_key_list failed

/tmp/tmp.ucwuHgbgNt/pubring.gpg

sec rsa1024/805110EB 2015-07-03
uid [ultimate] PGP2 is annoying <bugs@g10code.com>

sec rsa1024/805110EB 2015-07-03
uid [ultimate] PGP2 is annoying <bugs@g10code.com>

Details

Version
2.1.7-beta3
aheinecke set Version to 2.1.7-beta3.Jul 3 2015, 8:52 PM
aheinecke added subscribers: werner, aheinecke, neal.
thomas added a subscriber: thomas.Jul 4 2015, 8:43 AM

Two more details:

  1. All secret keys become unusable in this situation until you revert to a

backup of the public keyring, therefore I propose status "critical" (data loss)

  1. The duplicates (or even triplicates with my own keyring) of the keys only

have one uid, even if the original has more.

thomas raised the priority of this task from High to Unbreak Now!.Jul 4 2015, 8:43 AM
thomas added a comment.Jul 4 2015, 8:59 AM

Another small note: The problematic key was in wide-spread use and additionally
it was distributed until few years ago with Apache's KEYS file and still is
listed here: https://people.apache.org/keys/committer/lars.asc

And I would not call my keyring "very large", it contains less than 1700 keys,
mostly fetched using "keyserver-options auto-key-retrieve" when reading mailing
lists.

So it probably does not only affect me.

commit f05a63b fixes the main problem.
I'll now check why the migration creates a duplicate key.

werner added a comment.Aug 4 2015, 5:36 PM

Dup key fixed with commit 4a326d7

werner removed a project: In Progress.
aheinecke closed this task as Resolved.

Our tests show this works. Thanks!