Bug 693004

Summary:	gpg --list-config stalls while looking for card reader
Product:	[Fedora] Fedora	Reporter:	Barry Fishman <barry>
Component:	gnupg	Assignee:	Brian Lane <bcl>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	bcl, dueno, jonathan.underwood, kklic, nalin, rdieter, tmraz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-07 07:17:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Barry Fishman 2011-04-01 23:21:02 UTC

Description of problem:

I don't know if this is a gnupg or emacs problem.

When running gnus, emacs locks up and does not respond to a C-g C-g

Version-Release number of selected component (if applicable):

emacs 23.2
epg 1.0.0

This also happens in the bzr repository version.

How reproducible:

Always

Steps to Reproduce:
1. bring up emacs
2. select from menu tools/Read Net News (gnus)

Or just from command line:

$ emacs -q

and when emacs comes up, in the stratch buffer do:

(epg-configuration)^J
  
Actual results:

Emacs becomes unresponsive and does not free up with C-g C-g

Expected results:

Run gnus, or with the second test, display the gpg configuration information.

Additional info:

Works fine if the gpg-pgp-program is set to gpg2 rather than gpg.

After the last update 3/31, The 'gpg --with-colons --listconfig'
command does not return or respond to a control-c.  I assume we are
now supposed to run gpg2 "on the desktop" rather than gpg.

I noticed that emacs upstream (bzr repository) checks for both
but chooses gpg if its available (which is a bad choice for Lovelock)

Is this a emacs upstream mistake or is  the gpg command behaving badly?

Comment 1 Daiki Ueno 2011-04-06 09:53:58 UTC

As epg upstream, I would say that gpg shouldn't freeze with that command.

However, I couldn't reproduce this with the following versions:

gnupg-1.4.11-3.fc15.x86_64
gnupg2-2.0.17-1.fc15.x86_64
emacs-23.2-17.fc15.x86_64

Could you try running it under strace, to see which syscall causes the lockup?

strace -o strace-gpg.log gpg --with-colons --list-config

Comment 2 Barry Fishman 2011-04-06 12:24:55 UTC

It now works find and does not hangup.  So the bug report can be closed.

Much has changed on my system since the bug report, including a new kernel.

Gpg had hung up after completing its output.  One thing that differs between gpg and gpg2 (looking at the strace) is after output is produced gpg2 exits, while
gpg continues by scanning the /sys/bus/usb/devices directory.

This rings a bell since around the time I had the problem, when I had tried to shut off SELinux the system refused to boot with final message about a problem with /sys/bus/usb.  I have been having problems with the streamzap usb device
which is currently unplugged.

Comment 3 Daiki Ueno 2011-04-07 07:17:10 UTC

Thanks for the info.  Actually gpg v1 seems to scan USB ccid card readers on --list-config.  Reassigning to gnupg and closing for now.