Page MenuHome GnuPG
Create Task
Maniphest T3195

Scute does not reliably find the agent socket, especially if it is relocated to /run....
Closed, ResolvedPublic
Actions

Description

Quoting Damien:

After reading http://scute.org/scute.html/Troubleshooting.html
I noticed that $GPG_AGENT_INFO was not set.

Yes, GnuPG 2.1 does not use (nor set) that variable anymore. But Scute
still needs it in order to locate the socket, especially now that the
socket is no longer always located in $GNUPGHOME.

If I remember correctly, the problem goes like this:

  1. Scute looks for GPG_AGENT_INFO
  2. The variable does not exist, so Scute looks for the socket in $GNUPGHOME
  3. The socket is not there (because it is now somewhere under

[/var]/run), so Scute assume there's no running agent

  1. Scute spawns a new agent with the --use-standard-socket option (which

used to instruct the agent to create its listening socket in $GNUPGHOME,
but which has no effect with GnuPG 2.1)

  1. Scute still does not find the socket in $GNUPGHOME, and thus fails

with "Cannot connect to GPG Agent"

To avoid this, you need both to set the GPG_AGENT_INFO variable and make
sure that the agent is running before you start Firefox (simply calling
"gpg-connect-agent /bye" is enough).

Details

External Link
https://lists.gnupg.org/pipermail/gnupg-users/2017-June/058322.html

Event Timeline

justus created this task.Jun 6 2017, 9:46 AM
gouttegd added a subscriber: gouttegd.Jun 22 2017, 3:34 PM

I think the best method to make sure Scute can always find the socket is to use gpg-connect-agent to ask for the socket: we call gpg-connect-agent 'GETINFO socket_name' /bye and read the reply.

By doing this, we don't have to duplicate the logic of GnuPG's gnupg_socketdir() function (gnupg/common/homedir.c) to find the socket, and we are protected from any further change in that logic: if the location of the socket changes again in a future version of GnuPG, Scute won't need any fix.

Calling gpg-connect-agent also ensures that the agent will be started if it was not already running, again without having to duplicate the behavior of GnuPG's start_new_gpg_agent() function (gnupg/common/asshelp.c).

I proposed a patch set some time ago to implement this method, but it went without review. For what it's worth, I'm using this patch myself since then.

I don't entirely like the idea of forking a new process just to get the socket, but I don't think this is really a big deal--we only need to do that once, when Firefox (and thus Scute) is started. If we really want to avoid that, a compromise could be to first look for the socket under [/var]/run, and only if we can't find it we fallback to calling gpg-connect-agent. This way we would probably avoid the fork most of the time.

• werner assigned this task to justus.Jun 23 2017, 4:49 PM
• werner added a subscriber: • werner.

Justus, please apply the patches.

The other option would be that Damien gets write access to the Scute. Damien, do you want that? (justus: in that case, re-assign to me)

gouttegd added a comment.Jun 23 2017, 5:15 PM

Yes, I am ready to accept write access to the Scute repository.

By the way, I noticed that the Scute repository seems to be missing from dev.gnupg.org: it's not listed on the "Active Repositories" page (https://dev.gnupg.org/diffusion/) and there's nothing at https://dev.gnupg.org/source/scute.git where one would expect the repository to be.

justus reassigned this task from justus to • werner.Jun 27 2017, 11:19 AM
gouttegd added a comment.Jul 6 2017, 4:23 PM

Since there is no news for the last two weeks, I am wondering: am I the one blocking the situation here? Are you waiting for me to do something to make progress?

I have uploaded my SSH public key to my Phabricator profile. The patchset to fix this issue is on an isolated branch in my local repository, ready to be pushed as soon as I have write access.

Please tell me if there is anything else I need to do.

• werner added a comment.Jul 6 2017, 5:43 PM

The canonical repo is git://git.gnupg.org . We have not yet mirrored it at dev.gnupg.org.

Even as admin, I can't access your ssh key. Can you do me a favor and send it, possibly again, by priavte mail to wk@gnupg.org ?

gouttegd closed this task as Resolved.Jul 7 2017, 4:35 PM

OK, I pushed my fix into master.

Marking as resolved as I am using this fix myself for several months now.