Page MenuHome GnuPG

Gpgme/GnuPG 2 interaction broken
Closed, ResolvedPublic

Description

Gpgme 1.1.3 and gnupg 2.0.2 do not interact properly under some circumstances.

As an example, using gpgme

  • create a context,
  • select the signer's key,
  • create the input and output data objects, and then
  • call gpgme_op_sign().

Gpg-agent kicks in and calls pinentry to read the passphrase of the secret key.
Now click cancel in pinentry - and gpgme_op_sign() will return with exit code
0! (Log file attached, name gpgme-gnupg2.0.2.log)

Replacing gpg2 by gpg 1.4.5, everything works flawlessly (see attached log
gpgme-gnupg1.4.5.log). Please note that at the end of this log, apparently more
information about the failed operation is available (fd 33:
"MISSING_PASSPHRASE", "BAD_PASSPHRASE").

Details

Due Date
May 31 2007, 2:00 AM
Version
2.0.

Related Objects

Event Timeline

albrecht.dress set Version to 1.1.3.
albrecht.dress added a subscriber: albrecht.dress.

marcus added a project: gnupg.
marcus removed a project: gpgme.
marcus changed Version from 1.1.3 to 2.0..
marcus added subscribers: gnupg-hackers, marcus.

I can confirm this as a problem in gpg2, which behaves badly in the "pinentry
canceled" case:

$ gpg2 --status-fd 2 --sign --armor --use-agent

This is the result for gpg 1.4.6:
gpg: cancelled by user
[GNUPG:] MISSING_PASSPHRASE
[GNUPG:] BAD_PASSPHRASE 9FCD18563FC22AC8
gpg: no default secret key: bad passphrase
gpg: signing failed: bad passphrase

and this gpg2 2.0.4-svn4472:
gpg: cancelled by user
gpg: no default secret key: General error
gpg: signing failed: General error

This patch fixes the issue for me. It adds status writes for MISSING_PASSPHRASE
in the cancellation case. One of the main gpg developers should review the
patch, though, because the code flow is (overly?) complex already and there may
be a way to do this better.

marcus added a project: Restricted Project.Apr 26 2007, 11:33 PM
werner set Due Date to May 31 2007, 2:00 AM.May 7 2007, 3:45 PM
werner removed a project: Restricted Project.