Bug 894021

Description of problem:
importing an existing key from a file hangs up the client; the server gets stuck running gpg-agent and pinentry-curses processes.

Version-Release number of selected component (if applicable):
0.97-1.el6

How reproducible:
Need to set up client/bridge/server on CentOS 6

Steps to Reproduce:
1. set up a basic system according to the README
2. generate a gpg key on the client
3. export the gpg key to a file mykey.gpg
4. import the key to sigul with sigul import-key mykey mykey.gpg
   enter the passphrase of the key on the prompt, and a new passphrase twice.
  
Actual results:
no response; client doesn't return

Expected results:
client returns with result code

Additional info:

After lots of stracing, debugging, etc. we found that when gpg decides that it needs a passphrase to edit the key, it won't call back the _ChangePasswordResponder but rather start a gpg-agent, which in turn invokes a pinentry program because it needs a passphrase. 

The mail thread starting at http://lists.gnupg.org/pipermail/gnupg-users/2012-September/045414.html seems to suggest that this is by design since gnupg2, and there is no remedy for this other than to revert to using gnupg1 until gnupg2 implements the use of the agent feature pinentry-method=loopback.

As gnupg1 is not available on RHEL6 this issue breaks sigul on that platform.