GNOME Bugzilla – Bug 586855
seahorse-agent does not work with gnupg-2.0.12
Last modified: 2009-10-04 21:18:30 UTC
According to the release message[1], gnupg-2.0.12 uses a new command GETINFO with the agent which is not supported by seahorse-agent. Using gpg with seahorse-agent gives the following error message in /var/log/messages: seahorse-agent[65601]: unrecognized command: GETINFO The frontend itself says the following: gpg: problem with the agent: Not supported 1. http://lists.gnupg.org/pipermail/gnupg-announce/2009q2/000288.html
The FreeBSD folks also faced the same problem -- http://groups.google.com/group/mailing.freebsd.ports-bugs/browse_thread/thread/14e0f92d975dfdcf?pli=1
Did they introduce a similar change into gnupg-1.4.x?
(In reply to comment #2) > Did they introduce a similar change into gnupg-1.4.x? > I don't think so, 1.4.x is a maintenance branch, not a feature branch.
This also represents a regression in GPG as in gpg-1.4.x failure of the agent to return the passphrase would result in the user being prompted on the command line for the passphrase. gpg2 treats the failure to get the passphrase from the agent as a request to cancel the op. From g10/passphrase.c:363 /* Due to limitations in the API of the upper layers they consider an error as no passphrase entered. This works in most cases but not during key creation where this should definitely not happen and let it continue without requiring a passphrase. Given that now all the upper layers handle a cancel correctly, we simply set the cancel flag now for all errors from the agent. */ if (canceled) *canceled = 1; I don't get the message in /var/log/messages, but I do get the unsupported message which appears to be from a test for the repeat option in g10/call-agent.c:897 which is using the GETINFO call. The solution is to implement the GETINFO call which simply returns TRUE for being queried about supporting the repeat option for GET_PASSPHRASE. The repeat option then needs to be parsed and respected. /* GETINFO <what> Multipurpose function to return a variety of information. Supported values for WHAT are: version - Return the version of the program. pid - Return the process id of the server. socket_name - Return the name of the socket. ssh_socket_name - Return the name of the ssh socket. scd_running - Return OK if the SCdaemon is already running. cmd_has_option CMD OPT - Returns OK if the command CMD implements the option OPT. */ /* Return true if the commznd CMD implements the option OPT. */ static int command_has_option (const char *cmd, const char *cmdopt) { if (!strcmp (cmd, "GET_PASSPHRASE")) { if (!strcmp (cmdopt, "repeat")) return 1; } return 0; }
What's the timeframe for getting this worked-around in the 2.27 branch?
It's likely not going to happen in the 2.27 branch unless a patch is received as I'm working on finishing my dissertation at present.
Created attachment 143081 [details] [review] possible patch This patch allows gpg2 to sign some text and allowed Balsa (a mail client) to attach a Mime mode PGP signature. The "103 unknown command" may not be the correct message when the command is not exactly "GETINFO cmd_has_option GET_PASSPHRASE repeat"--I couldn't find any documentation about the format of those messages.
Created attachment 143200 [details] [review] better patch This patch not only advertizes that GETINFO is implemented, it actually parses --repeat and respects it. Well...gpg-agent parses --repeat=<n> and asks for <n> confirmations, with <n> additional pinentry popups for confirmation of the passphrase. The patch assumes that n <> 0 means confirm (once!), and uses the confirm=TRUE option of seahorse_passphrase_prompt_show. That seems to be a reasonable interpretation.
Created attachment 143228 [details] [review] more careful patch Here's a more robust version--also with the code broken out.
Comment on attachment 143228 [details] [review] more careful patch Committed thanks.