Hello, I updated to gnupg-2.1.9 from 2.0.x on both my desktop and laptop and now I have big problems. 1. gpgme is now broken. Gpgme consumers (e.g. sylpheed, mcabber) can verify, encrypt and decrypt messages, but can't sign them. On signing I have the following issues: Please enter your PGP passphrase: [17:26:06] GPGME signature error: Unusable secret key Or: ** Sylpheed-WARNING: pgp_sign(): signing failed: User defined error code 1 I _can_ sign using the very same keys and plain gpg -s --default-key $id command. GPG itself works fine, something is amiss with gmgme. I updated gpgme, libgcrypt, libgpg-error and libassuan to the latest unstable versions and rebuilt consumer applications. Of course, keys were migrated to the new format using gpg --import and gpg-agent was restarted (I even rebooted the whole host), but problem is still here. The problem is even more strange, since I found a workaround way to sign messages in sylpheed. Program has three options for key selection: a) use default GPG key; b) select key by e-mail; c) use key with provided ID. Options b) and c) cause the error above, while option a) works, so by editing gpg.conf I can set default key id to what I need to sign a message. This is very inconvenient (since I have many keys), but at least works somehow. 2. I have duplicated keys in the ring with the same ID and fingerprint. Duplication happens only to _some_ of my keys where I have a secret key, fetched public keys of other users are not duplicated. Examples: a) Here I have the very same key twice: $ gpg --fingerprint -K 0x8EE705C07CFA83D3 sec rsa4096/0x8EE705C07CFA83D3 2012-09-11 [expired: 2015-09-11] Key fingerprint = 3F2D 1E49 4F96 2CE6 1597 F217 8EE7 05C0 7CFA 83D3 uid [ expired] Bircoph sec rsa4096/0x8EE705C07CFA83D3 2012-09-11 [expired: 2015-09-11] Key fingerprint = 3F2D 1E49 4F96 2CE6 1597 F217 8EE7 05C0 7CFA 83D3 uid [ expired] Bircoph b) Now comes more interesting: $ gpg --fingerprint -K 0x565953B95372756C sec rsa4096/0x565953B95372756C 2013-02-27 [expires: 2018-02-26] Key fingerprint = 63EB 04FA A30C 76E2 952E 6ED6 5659 53B9 5372 756C uid [ultimate] Andrew Savchenko uid [ultimate] Andrew A. Savchenko (NRNU MEPhI) uid [ultimate] Andrew A. Savchenko (UT Department) uid [ultimate] Andrew Savchenko (Gentoo Dev) uid [ultimate] Andrew A. Savchenko (XMPP) uid [ultimate] Andrew A. Savchenko (UT Department) uid [ultimate] Andrey Savchenko (RHIC) ssb rsa4096/0x7AB649CA518C8321 2013-02-27 [expires: 2018-02-26] ssb rsa4096/0xF6535A33BA1EE48D 2015-01-13 [expires: 2018-01-12] sec rsa4096/0x565953B95372756C 2013-02-27 [expires: 2018-02-26] Key fingerprint = 63EB 04FA A30C 76E2 952E 6ED6 5659 53B9 5372 756C uid [ultimate] Andrew A. Savchenko (NRNU MEPhI) uid [ultimate] Andrew Savchenko uid [ultimate] Andrew Savchenko (Gentoo Dev) uid [ultimate] Andrew A. Savchenko (XMPP) uid [ultimate] Andrew A. Savchenko (UT Department) uid [ultimate] Andrew A. Savchenko (UT Department) ssb rsa4096/0x7AB649CA518C8321 2013-02-27 [expires: 2018-02-26] ssb rsa4096/0xF6535A33BA1EE48D 2015-01-13 [expires: 2018-01-12] I have two versions of the same key: the latest and previous one (before I added one more e-mail uid to the key). This problem may be related to the first one, may be not, I'm not sure. It is possible that gpgme goes crazy with these duplicates. I have no idea how to remove duplicates and old versions. All gpg commands are tied to either key id, e-mail or fingerprint. They are all not unique to delete such duplicates. I have though that this may happen due to both secring.gpg and private-keys-v1.d present, but moving secring.gpg away doesn't help. Maybe manual editing of pubring.gpg will help to remove duplicates, but it will be quite hard to handle this binary format. Googling gave me very litte here: 1st issue: may happen for some custom gpgme client software, but no data on global failures after gnupg update. 2nd issue: may happen when key is stored in multiple sources and fetched from them, but I have no --keyring options in my gpg.conf (see attached file). Any ideas how to fix these issues, especially the signing failure are much appreciated. Best regards, Andrew Savchenko