gpgme passphrase_cb (problem solved)

[John Morris]

Hi list,

I believe I've figured out the bigger problem.

On 09/07/2012 08:23 PM, John Morris wrote:
> I still have not found a case where passphrase_cb is actually used. In
> the gpg2 manpage, the description of the '--{no-}use-agent' options
> indicate that the gpg agent is *always* used, which would imply that
> there is no way for gpg2 to read in a passphrase through a file descriptor.

I'm pretty sure now that this is correct:  gpg2 password input cannot be 
captured without the use of a gpg-agent.

> The gpgme test cases work because they create a 'gpg-agent.conf' file in
> $GNUPGHOME pointing to the simple but workable 'pinentry' script in the
> same directory. Although there is a 'passphrase_cb' function defined in
> t-support.h, it is presumably never used with gpg2, even though it is
> set up and ready to go.

Has there been any thought about building a gpg-agent into gpgme that 
the passphrase_cb could be hooked into?  The passphrase_cb is a pretty 
convenient interface, since it can be implemented without worrying about 
creating dummy pinentry programs and pointing gpg-agent.conf files at them.

> The pygpgme test cases fail because, although there is a working
> passphrase_cb, it is never called, and there is no gpg-agent configured
> capable of supplying the passphrase.

I demonstrated that the failing cases can by fixed by inserting a line 
after the ctx object is initialized to run gpg instead of gpg2:

         ctx.set_engine_info(gpgme.PROTOCOL_OpenPGP, '/usr/bin/gpg',
                             os.environ['GNUPGHOME'])

> All the above seems to be true, and yet the application I'm having
> trouble with (sigul) was working well a couple of months ago. Can anyone
> confirm or deny the above?

If the above example will be applied, I believe my solution is imminent. 
  Thanks for the bandwidth, and enjoy the weekend.

	John