Still running into the GPG_AGENT_INFO bug in 0.3

[Francois Schiettecatte]

I am running into the same bug described in:

  https://bugs.launchpad.net/pygpgme/+bug/271758

and:

  https://bugs.launchpad.net/pygpgme/+bug/389165

Unsetting GPG_AGENT_INFO in the environment and in my code does not cause the ctx.passphrase_cb to be called and I get a dialog in the terminal asking me for a passphrase.

I am using the same code that is in test_encrypt_symmetric() in test_encrypt_decrypt.py .

Let me know if you need more information from me.

[Max Parmer (maxp-h)]

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

[James Henstridge (jamesh)]

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

[Francois Schiettecatte (fschiettecatte)]

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.

[James Henstridge (jamesh)]

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.

[Francois Schiettecatte (fschiettecatte)]

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)

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

[John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr)]

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.

[John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr)]

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.

[John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr)]

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).

[John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr)]

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.