GPG Operation Cancelled

Symptom:

After upgrading from gpg2-2.0.x to gpg2-2.1.x you find that all operations requiring your secret key, such as signing and encryption, get cancelled. Sample error message:

gpg: /tmp/test.txt: clearsign failed: Operation cancelled

What's happening:

To do the crypto operations, gpg starts gpg-agent, and to read the secret (private) key, gpg-agent obtains the passphrase (which it also saves for re-use later) by calling pinentry. The protocol by which gpg-agent talks to pinentry has changed, and there is no version check (or it's not enforced effectively), and pinentry never asks for nor delivers the passphrase, precluding operations requiring the secret key. By the time the problem report propagates back to the error message that the user sees, the message is not very informative.

How to fix:

Upgrade the various pinentry packages to version 1.0.0 or later. I have pinentry and pinentry-gtk2 installed; there are others as well. (gpg-agent is part of the gpg2 package and so will already be upgraded.)

Additional gotcha:

I was installing RoundCube (roundcubemail package), the Enigma plugin for signing and encrypting messages. This is a PHP script that runs as the Apache user (wwwrun:www on a SuSE system) and requires a copy of the user's secret key; it has a settings page on which you can import your key, as well as public keys of trusted correspondents.

To debug the cancelled issue, I did approximately this (as root), where $PWD = the directory where it keeps the keyring:

su --login --shell /bin/bash wwwrun
cd /srv/www/roundcubemail/plugins/enigma/home/jimc
gpg --homedir $PWD -o /tmp/test.signed --clearsign /tmp/test.txt

After I upgraded pinentry, it complained about permission denied. But on what file; it has permission for all the ones listed and the containing directory. strace revealed that pinentry was trying to ask for the passphrase using the session's controlling TTY, which had permission 640 root:tty, excluding wwwrun. I tried changing permissions on the tty but that was not effective. For a quick fix I provided the X-Windows session cookie to wwwrun. Now it was able to use pinentry-gtk2 to solicit the passphrase, and crypto operations succeeded.

This problem is not encountered in production with RoundCube Enigma, because it has its own procedure (pinentry equivalent) to solicit the passphrase by a web pop-up (Javascript).

Caveat: As of roundcubemail-1.2.2-2.1 it does not use the Web of Trust. You should assess trust manually, and only import the public keys of trusted users to your RoundCube keyring. This is going to be improved, but is not finished.

Non-Caveat: The passphrase(s) are stored encrypted in the RoundCube session cookie, and inimical other users will not have this cookie. The gpg-agent is individual per user and does not persist, and so other users cannot access it.