GnuPG fails to update keyring files in certain circumstances
Closed, ResolvedPublic

Description

This causes the distcheck target of gpgme to fail: https://jenkins.gnupg.org/job/gpgme/XTARGET=distcheck,label=master/750/

For some reason, there is both a keyring and a keybox, but only the keyring is updated. Looks like the key in the keybox requires reordering, and because that is only done in the keyring, GnuPG will attempt this over and over:

jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ GNUPGHOME=$(pwd) top_srcdir=/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23 gpg --list-key alfa|grep sub |wc
gpg: WARNING: unsafe permissions on homedir '/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg'
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!
     12      48     340
jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ ls -l pubring*
-rw------- 1 jenkins jenkins 30922 Apr 10 16:33 pubring.gpg
-rw------- 1 jenkins jenkins 29826 Apr 10 16:27 pubring.gpg~
-rw-r--r-- 1 jenkins jenkins 21433 Apr 10 16:18 pubring.kbx
-rw-r--r-- 1 jenkins jenkins 19766 Apr 10 16:18 pubring.kbx~
-rw-r--r-- 1 jenkins jenkins     2 Apr 10 16:17 pubring-stamp
jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ ls -l pubring.{gpg,kbx}
-rw------- 1 jenkins jenkins 30922 Apr 10 16:33 pubring.gpg
-rw-r--r-- 1 jenkins jenkins 21433 Apr 10 16:18 pubring.kbx
jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ GNUPGHOME=$(pwd) top_srcdir=/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23 gpg --edit-key alfa 
gpg: WARNING: unsafe permissions on homedir '/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg'
gpg (GnuPG) 2.1.21-beta42; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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!
uid  Alfa Test (demo key) <alfa@example.net>
sig!3        2D727CC768697734 2017-04-10 never       [self-signature]*
             [primary]
uid  Alpha Test (demo key) <alpha@example.net>
sig!3        2D727CC768697734 1999-03-08 never       [self-signature]
sig!3        2D727CC768697734 2017-04-10 never       [self-signature]*
uid  Alice (demo key) (reordered signatures follow)
sig!3        2D727CC768697734 2017-04-10 never       [self-signature]
uid  Alfa Test (demo key) <alfa@example.net> (reordered signatures follow)
sig!3        2D727CC768697734 1999-03-08 never       [self-signature]
sub  6AE6D7EE46A871F8
sig!         2D727CC768697734 1999-03-08 never       [self-signature]*
key 2D727CC768697734:
5 duplicate signatures removed
2 signatures reordered
Warning: errors found and only checked self-signatures, run 'check' to check all signatures.
Secret key is available.

sec  dsa1024/2D727CC768697734
     created: 1999-03-08  expires: never       usage: SCA 
     trust: unknown       validity: unknown
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage: E   
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage:     
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage: E   
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage: E   
ssb  elg1024/6AE6D7EE46A871F8
     created: 1999-03-08  expires: never       usage: E   
[ unknown] (1). Alfa Test (demo key) <alfa@example.net>
[ unknown] (2)  Alpha Test (demo key) <alpha@example.net>
[ unknown] (3)  Alice (demo key)

gpg> save
jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ ls -l pubring.{gpg,kbx}
-rw------- 1 jenkins jenkins 32018 Apr 10 16:38 pubring.gpg
-rw-r--r-- 1 jenkins jenkins 21433 Apr 10 16:18 pubring.kbx
jenkins@soro:/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg$ GNUPGHOME=$(pwd) top_srcdir=/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23 gpg --list-key alfa|grep sub |wc
gpg: WARNING: unsafe permissions on homedir '/tmp/tmp.ifyMthymNU/gpgme-1.9.1-beta23/_build/sub/tests/gpg'
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!
     16      64     452
justus created this task.Apr 10 2017, 4:41 PM
languitar added a subscriber: languitar.

I suspect my issue T3123 is a duplicate of this. Did anyone find a solution how to get out of this situation?

justus claimed this task.May 4 2017, 11:07 AM

This has nothing to do with the keybox file.

justus renamed this task from GnuPG duplicates binding signatures in certain circumstances to GnuPG fails to update keyring files in certain circumstances.May 4 2017, 11:26 AM
justus triaged this task as High priority.

If I hack the test suite to use the old keyring format, I see two tests failing:

Checking quick key generation... 
Checking that we can add a user ID... 
Key capabilities changed when adding a user id:
  Pre: ((pub - 2048 1 3C456A439FBAFB57 1493889537 1556961537  u   scESC      23  ) (sub - 2048 1 7E79B1661AAD10A8 1493889537      e      23))
 Post: ((pub - 2048 1 3C456A439FBAFB57 1493889537 1556961537  u   scESC      23  ) (sub - 2048 1 7E79B1661AAD10A8 1493889537      e      23) (sub - 2048 1 7E79B1661AAD10A8 1493889537      e      23))
FAIL: tests/openpgp/quick-key-manipulation.scm 
[...]
/home/teythoon/repos/g10/gnupg/obj/../tests/openpgp/delete-keys.scm:80: Assertion failed: : ((not (have-public-key? subkey)))
0: (throw (string-append "/home/teythoon/repos/g10/gnupg/obj/../tests/openpgp/delete-keys.scm" ":" "80" ": Assertion failed: ") '(not (have-public-key? subkey)))
FAIL: tests/openpgp/delete-keys.scm

We should either (and preferably) have exactly one format that we use to store public keys, or parametrize the test suite so that all tests are run with both formats.

justus removed justus as the assignee of this task.May 4 2017, 2:23 PM
bmhatfield added a subscriber: bmhatfield.EditedMay 8 2017, 3:15 PM

Just wanted to chime in and say I am hitting this as well:

% gpg --version
gpg (GnuPG) 2.1.20
libgcrypt 1.7.6

Is there a workaround? I'm not sure of the difference between a keybox and a keyring, but I did "upgrade" my stuff to the new format, so potentially I could clear something out.

justus added a comment.May 8 2017, 3:27 PM

This bug affects GnuPG 2.1.20 when using keyrings (I guess most users upgrading from older versions do). This is fixed in 22739433e98be80e46fe7d01d52a9627c1aebaae.

Any plans when this change will be pushed into a release version so that it ends up in distros?

I found a workaround that may benefit folks who previously upgraded and are now only using GnuPG 2.1+ - upgrade your keyring to keybox format: https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox

Any plans when this change will be pushed into a release version so that it ends up in distros?

I created a task for that: T3150.

I found a workaround that may benefit folks who previously upgraded and are now only using GnuPG 2.1+ - upgrade your keyring to keybox format: https://www.gnupg.org/faq/whats-new-in-2.1.html#keybox

I can't confirm that this works. Initially, the subkeys with empty capabilities ([]) are gone, however, once I start editing the key again and save it, I am back to the original issue I have described in T3123:

languitar@miles ~/.gnupg> gpg --list-keys private
pub   rsa4096/0xBDC65D51C7196F97 2015-05-01 [SC] [expires: 2017-10-22]
      Key fingerprint = D860 BE63 FF5B 1B3F CD69  F2A5 BDC6 5D51 C719 6F97
uid                   [ultimate] Johannes Wienke (Private activities) <languitar@semipol.de>
sub   rsa4096/0xA4226A8F21470CF9 2015-05-01 [E] [expires: 2019-05-04]
sub   rsa4096/0x8714EE96045C4FBC 2015-05-01 []
sub   rsa4096/0x769A045782C52046 2015-05-01 []
sub   rsa4096/0xBFBEC7E173D9FBCB 2017-04-27 [A] [expires: 2017-10-24]
sub   rsa4096/0x8714EE96045C4FBC 2015-05-01 [S] [expires: 2017-10-22]
sub   rsa4096/0x8714EE96045C4FBC 2015-05-01 [S] [expires: 2017-05-16]
sub   rsa4096/0xBFBEC7E173D9FBCB 2017-04-27 []
sub   rsa4096/0xA4226A8F21470CF9 2015-05-01 []
sub   rsa4096/0x8714EE96045C4FBC 2015-05-01 []

pub   rsa4096/0x59B8929E62335B59 2015-05-11 [SC]
      Key fingerprint = C02F 859A 1E2B 7C0D 5FEA  1D60 59B8 929E 6233 5B59
uid                   [ultimate] passwords-private
sub   rsa4096/0x1719FB5F95163AA7 2015-05-11 [E]

After migrating as explained in the link my .gnupg folder looks like this:

languitar@miles ~/.gnupg> ls
S.gpg-agent              S.gpg-agent.ssh          dirmngr.conf             otrust.lst               pubring.gpg~             random_seed              sks-keyservers.netCA.pem trustdb.gpg
S.gpg-agent.browser      S.scdaemon               gpg-agent.conf           private-keys-v1.d        pubring.kbx              reader_0.status          sshcontrol               trustdb.gpg.bak
S.gpg-agent.extra        crls.d                   gpg.conf                 publickeys               pubring.kbx~             secring.gpg              tofu.db
justus closed this task as Resolved.May 15 2017, 10:16 AM
justus claimed this task.

The OpenPGP test suite is now run once with keyboxes and once with keyrings, so backend-specific bug like this will be caught in the future.

justus merged a task: Restricted Maniphest Task.May 15 2017, 10:23 AM
justus added a subscriber: vanitasvitae.