After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586855 - seahorse-agent does not work with gnupg-2.0.12
seahorse-agent does not work with gnupg-2.0.12
Status: RESOLVED FIXED
Product: seahorse-plugins
Classification: Applications
Component: Agent
unspecified
Other Linux
: Normal major
: 2.24
Assigned To: seahorse-plugins-maint
seahorse-plugins-maint
Depends on:
Blocks:
 
 
Reported: 2009-06-24 15:18 UTC by Nirbheek Chauhan
Modified: 2009-10-04 21:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
possible patch (1.31 KB, patch)
2009-09-12 20:11 UTC, Peter Bloomfield
none Details | Review
better patch (3.57 KB, patch)
2009-09-14 23:48 UTC, Peter Bloomfield
none Details | Review
more careful patch (4.57 KB, patch)
2009-09-15 12:50 UTC, Peter Bloomfield
committed Details | Review

Description Nirbheek Chauhan 2009-06-24 15:18:20 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
Comment 1 Nirbheek Chauhan 2009-06-24 15:20:33 UTC
The FreeBSD folks also faced the same problem -- http://groups.google.com/group/mailing.freebsd.ports-bugs/browse_thread/thread/14e0f92d975dfdcf?pli=1
Comment 2 Adam Schreiber 2009-06-24 15:24:52 UTC
Did they introduce a similar change into gnupg-1.4.x?
Comment 3 Nirbheek Chauhan 2009-06-25 18:28:52 UTC
(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.
Comment 4 Adam Schreiber 2009-06-25 21:59:48 UTC
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;
}
Comment 5 Nirbheek Chauhan 2009-07-06 17:13:21 UTC
What's the timeframe for getting this worked-around in the 2.27 branch?
Comment 6 Adam Schreiber 2009-07-10 13:39:55 UTC
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.
Comment 7 Peter Bloomfield 2009-09-12 20:11:37 UTC
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.
Comment 8 Peter Bloomfield 2009-09-14 23:48:25 UTC
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.
Comment 9 Peter Bloomfield 2009-09-15 12:50:25 UTC
Created attachment 143228 [details] [review]
more careful patch

Here's a more robust version--also with the code broken out.
Comment 10 Adam Schreiber 2009-10-04 21:18:18 UTC
Comment on attachment 143228 [details] [review]
more careful patch

Committed thanks.