Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#43173 - [gnupg] 2.1.1-1 results in "gpg: keydb_search_first failed: Invalid packet"

Attached to Project: Arch Linux
Opened by Thomas Jäger (xunil64) - Saturday, 20 December 2014, 14:14 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 24 February 2015, 16:03 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No

Details

Description:
After upgrading to gnupg 2.1.1-1 the gpg keys cannot be used/read any longer


Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:

# === gpg-2.1.0-6 ===
# gpg --list-keys
# <any keys listed>

# === gpg-2.1.1-1 ===
# gpg --list-keys
gpg: keydb_search_first failed: Invalid packet




This task depends upon

Closed by  Gaetan Bisson (vesath)
Tuesday, 24 February 2015, 16:03 GMT
Reason for closing:  Fixed
Additional comments about closing:  gnupg-2.1.2-1
Comment by Thomas Jäger (xunil64) - Saturday, 20 December 2014, 14:16 GMT
After downgrading to gnupg-2.1.0-6 gpg works fine again
Comment by Gaetan Bisson (vesath) - Saturday, 20 December 2014, 18:18 GMT
Can you report this upstream to http://bugs.g10code.com/ ?

Providing a pubring.gpg that exhibits this behavior would help debugging.
Comment by Duncan Idaho (duncanidaho) - Sunday, 21 December 2014, 10:28 GMT
I can confirm that GnuPG 2.1.1 behaves strange. I noticed that this version can only seen 1 out of my 3 private keys. Interestingly, it was the first and thus the oldest key. Downgrading back to gnupg-2.1.0-7-x86_64 solves the problem.
Comment by Michael Laß (Bevan) - Sunday, 21 December 2014, 13:28 GMT
I also suffer from this problem and could track it down to a specific commit. I opened a bugreport upstream: https://bugs.g10code.com/gnupg/issue1793
Comment by Christopher Beck (beckus) - Sunday, 21 December 2014, 14:26 GMT
Another hint for smart card users: Downgrading to 2.1.0-6 works well on all keys except that ones residing on a smart card. Downgrading gnupg to 2.0.26 and reinstalling dirmng (1.1.1-3) and gpgme (1.5.2-1) works. I'll wait for this bug to be closed, perhaps the fix on that will solve the other problem, too.
Comment by Razvan Cojocaru (rc) - Monday, 22 December 2014, 15:43 GMT
I have the same problem:

$ gpg --list-keys
gpg: keyring_get_keyblock: read error: Invalid packet
gpg: keydb_get_keyblock failed: Invalid keyring

Used to work just fine before the upgrade.
Comment by Uwe Koloska (kolewu) - Monday, 22 December 2014, 16:09 GMT
I have had the same problem -- but found a workaround that probably helps in debugging, too.

I just removed the old ~/.gnupg directory, by renaming it to dot.gnupg and then imported the pub- and secring from the old dir:

$ gpg --import dot.gnupg/pubring.gpg
$ gpg --import dot.gnupg/secring.gpg

Then copy the trustdb:

$ cp dot.gnupg/trustdb.gpg .gnupg/

I am not sure, whether this procedures preserves the whole former behaviour (gnupg.conf and the other configuration files, I have left out by purpose!), but it works for me and for now.
Comment by Chester Wisniewski (chetwisniewski) - Saturday, 27 December 2014, 19:58 GMT
The workaround worked for me. Thanks Uwe.

Chester
Comment by Stephan Windmüller (windy) - Tuesday, 24 February 2015, 08:56 GMT
The issue seems to be gone with 2.1.2.
Comment by Michael Laß (Bevan) - Tuesday, 24 February 2015, 10:44 GMT
I also cannot reproduce it anymore. I closed the upstream report.
Comment by Georg (georgnix) - Tuesday, 24 February 2015, 11:06 GMT
Confirmed.
Upstream as above: https://bugs.g10code.com/gnupg/issue1793
Comment by Gaetan Bisson (vesath) - Tuesday, 24 February 2015, 16:02 GMT
Great. Thanks for working with upstream on this.

Loading...