Still running into the GPG_AGENT_INFO bug in 0.3

I also observe this issue with the most recent revision from the Devel branch and also 0.3. Running the test suite yields password prompts from the agent when the simple passphrase_cb should be called. Unsetting GPG_AGENT_INFO and GPG_TTY doesn't stop the prompts, nor does unsetting them and killing all running gpg-agents.

I observe this on Fedora 17:
$ rpm -qa 'gpgme*|gnupg*'
gpgme-1.3.0-8.fc17.x86_64
gnupg-1.4.12-1.fc17.x86_64
gnupg2-2.0.18-3.fc17.x86_64
gpgme-devel-1.3.0-8.fc17.x86_64

$ uname -a
Linux localhost 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21 22:32:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

How exactly are you unsetting GPG_AGENT_INFO? Are you doing it before or after importing the gpgme module?

I can't remember, it was a while ago. I probably did ' unset ' and ' export GPG_AGENT_INFO="" ' on the command line and 'del os.environ['GPG_AGENT_INFO']' in my python code. And I probably also did a 'print os.environ['GPG_AGENT_INFO']' in the python code to check. I spent a while trying to figure it out.

Happy to (re)run some tests if you want.

I just did a few tests using encrypt_sign() and no passphrase_cb set. The test first succeeded in signing the plain text, which indicates that it was accessing the agent.

I then added a "del os.environ['GPG_AGENT_INFO']" call just before the encrypt_sign() call and got a "Bad passphrase" error instead, indicating that the agent was not being used. Presumably I could have fixed the test program with a passphrase callback (the tests for this behaviour pass).

So a test case would be useful.

Here is the code I use, GPG_AGENT_INFO is not set in the environment, and this is the output when I cancel in the dialog box:

linux: ~ > ./sample.py
None
Traceback (most recent call last):
  File "./sample.py", line 40, in <module>
    ctx.decrypt(cipher, plain)
gpgme.GpgmeError: (7, 11, u'Bad passphrase')

---------------

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import gpgme
from io import BytesIO

#--------------------------------------------------------------------------

import os
import gpgme
from io import BytesIO

# os.environ['GNUPGHOME'] = '/home/francois/.gnupg'

print os.environ.get('GPG_AGENT_INFO')
# del os.environ['GPG_AGENT_INFO']

# Encrypt
ctx = gpgme.Context()

key = ctx.get_key('85753E63C68C07937010BD162808A32D68228AD7')
plain = open('/home/francois/francois.pl', 'rb')
cipher = open('/home/francois/francois.pl.gpg', 'wb')

ctx.encrypt([key], 0, plain, cipher)

plain.close()
cipher.close()

# Decrypt
ctx = gpgme.Context()

key = ctx.get_key('85753E63C68C07937010BD162808A32D68228AD7')
cipher = open('/home/francois/francois.pl.gpg', 'rb')
plain = open('/home/francois/francois1.pl', 'wb')

ctx.decrypt(cipher, plain)

cipher.close()
plain.close()

exit (0)

#--------------------------------------------------------------------------

Hi, I'm having the same problem. Fedora 16, pygpgme 0.3, gpgme 1.3.0, gnupg 2.0.18.

I posted to the gnupg-users list while debugging over a couple of days. See the latest message here:

http://lists.gnupg.org/pipermail/gnupg-users/2012-September/045417.html

The pygpgme unit tests don't complete, instead bringing up the gtk pinentry dialog.

Up to now, my digging points to gpg2 simply not allowing passphrases through a file descriptor and only through a gpg-agent. However, I'm not convinced because the app, 'sigul', part of the Fedora buildsys software, was working a couple of months ago on Fedora 17 (that's a difference I'll explore today).

I'd appreciate pointers for where to look next. I'm happy to help debug, not afraid of the source, and it appears I have a live manifestation of the above bug, but I'm unfamiliar with gnupg.

One more point of reference:

The fedora SRPM %check script, which runs 'make check', contains the following comments:

### Can't run the tests unconditionally because they depend on importing a private key.
# gpg2 on which our gpgme library depends does not import private keys so this
# won't work. The issue in the real world is not so big as we don't
# manipulate private keys outside of a keyring that often.
# We'll run this and ignore errors so we can manually look for problems more easily

As happens with my manual runs of 'make check', the 'test_sign_with_passphrase_cb' and 'test_encrypt_symmetric' tests both fail.

I'm becoming more convinced that gpg2 really does require a gpg-agent.

gpg2 was indeed the culprit.

In the test cases, adding the following line after initializing the 'ctx' context variable fixes things:
        ctx.set_engine_info(gpgme.PROTOCOL_OpenPGP, '/usr/bin/gpg',
                            os.environ['GNUPGHOME'])

Perhaps the test cases could be configurable to use either gpg or gpg2. If they are set to use gpg2, they could omit the tests that fail (until someone thinks of a good way to connect a gpg-agent that is hooked into gpgme and a passphrase_cb function).

One further wrinkle that should be confirmed by someone else:

The /usr/bin/gpg binary installed by gnupg v.2 packages is not binary compatible with that by gnupg v.1 packages. The v.1 gpg binary works with gpgme and passphrase_cb; the v.2 binary seems not to work with gpgme and passphrase_cb.

I worked around my original problem by recompiling the 'gnupg' and 'gnupg2' RPMs from fc16 and installing on el6. el6 (older than fc16) provides only gnupg2, and fc18 (newer than fc16, of course) also only provides gnupg2, so somewhere in the middle something curious happened. I'm done with this, though, so any further work will have to be taken up by someone else. :)

Thanks for the cool gpgme wrapper, I like it.