FS#49280 - [gnupg] segfault after importing key

Attached to Project: Arch Linux
Opened by David (da) - Monday, 09 May 2016, 20:20 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 11 May 2016, 19:58 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: gpg -k segfaults after importing key


Additional info: gnupg 2.1.12-1


Steps to reproduce:

# gpg --import <( curl -s "http://pgp.mit.edu/pks/lookup?op=get&search=0x79BE3E4300411886" )
gpg: key 00411886: public key "Linus Torvalds <torvalds@linux-foundation.org>" imported
gpg: Total number processed: 1
gpg: imported: 1

gpg: signal Segmentation fault caught ... exiting
Segmentation fault (core dumped)
This task depends upon

Closed by  Gaetan Bisson (vesath)
Wednesday, 11 May 2016, 19:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  gnupg-2.1.12-2 in [testing]
Comment by Doug Newgard (Scimmia) - Monday, 09 May 2016, 21:12 GMT
No problem for me. Entire system up to date? Backtrace?
Comment by David (da) - Tuesday, 10 May 2016, 07:45 GMT
Thanks, working now; not sure, if linux 4.5.3-1 fixed it for me. /edit: Seems my ~/.gnupg/trustdb.gpg gets corrupted.
Comment by Steven (Stebalien) - Wednesday, 11 May 2016, 06:42 GMT
  • Field changed: Percent Complete (100% → 0%)
I can reliably reproduce this bug on linux 4.5.3 and deleting trustdb.gpg doesn't fix it. Basically, importing any key seems to cause gpg to segfault from then on. Downgrading, running gpg, and then upgrading seems to fix the corrupted database (until another key is imported).
Comment by Vincent Brillault (Feandil) - Wednesday, 11 May 2016, 07:06 GMT
The trigger for me seems to be "update-trustdb", but I can't reproduce it on a new keyring.
With my own keyring, it is segfaulting on every call on a up-to-date system (no testing):
'''
% gpg --update-trustdb
gpg: removing stale lockfile (created by 19453)
gpg: public key 0x7B8FA05E550FDA19 is 25 seconds newer than the signature
gpg: public key 0x70929A9C6DC31821 is 6699 seconds newer than the signature
gpg: public key 0x70929A9C6DC31821 is 6681 seconds newer than the signature
gpg: public key 0x34F0AD94868FADC1 is 1158 seconds newer than the signature
gpg: public key 0xBB2331BFC5D30BFB is 2076 seconds newer than the signature

gpg: signal Segmentation fault caught ... exiting
zsh: segmentation fault (core dumped) gpg --update-trustdb
'''

After downgrading to gnupg-2.1.11-1, works as expected:
'''
% gpg --update-trustdb
gpg: removing stale lockfile (created by 19717)
gpg: public key 0x7B8FA05E550FDA19 is 25 seconds newer than the signature
gpg: public key 0x34F0AD94868FADC1 is 1158 seconds newer than the signature
gpg: public key 0xBB2331BFC5D30BFB is 2076 seconds newer than the signature
gpg: marginals needed: 3 completes needed: 1 trust model: PGP
gpg: depth: 0 valid: 3 signed: 12 trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1 valid: 12 signed: 18 trust: 0-, 0q, 1n, 10m, 1f, 0u
gpg: next trustdb check due at 2016-11-27
'''

Attached the full stack trace obtained after recompiling the packages in -O0, debug and !strip.
GDB segfault details::
'''
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7453fcb in _gcry_mpi_normalize (a=0x0) at mpi-bit.c:61
61 for( ; a->nlimbs && !a->d[a->nlimbs-1]; a->nlimbs-- )
'''
   trace.log (4.7 KiB)
Comment by Vincent Brillault (Feandil) - Wednesday, 11 May 2016, 09:33 GMT
Bug open upstream: https://bugs.gnupg.org/gnupg/issue2351
Comment by Vincent Brillault (Feandil) - Wednesday, 11 May 2016, 11:07 GMT
Upstream has released a fix (which at least fixes my case): http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=83a90a916e8e2f8e44c3b11d11e1dd75f65a87fb

Loading...