Bug 693004 - gpg --list-config stalls while looking for card reader
Summary: gpg --list-config stalls while looking for card reader
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: gnupg
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-01 23:21 UTC by Barry Fishman
Modified: 2011-04-07 07:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-07 07:17:10 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.