Page MenuHome GnuPG
Create Task
Maniphest T859

gpg-agent and "--use-standard-socket" confusion
Closed, ResolvedPublic
Actions

Description

This seems to be a bug, at least it's potentially confusing -

If you start the agent like this:

gpg-agent --daemon --use-standard-socket

then the agent uses ~/.gnupg/S.gpg-agent as designed but it also spits out the
env var setup for GPG_AGENT_INFO using a temp socket name including the process
ID. This is a little confusing since if you are doing the common:

eval gpg-agent --daemon --use-standard-socket

invocation, then you are setting GPG_AGENT_INFO which now points to an unused
socket (which doesn't exist). Since gpg looks in the environment first and falls
back on the standard socket if it can't find the env var, this can lead to agent
connection failures even though everything looks like it's set up ok. Perhaps if
the "--use-standard-socket" option is used, the agent shouldn't spit anything to
STDOUT on startup or should at least split out a socketname which corresponds to
the standard socket name?

Details

Version
2.0.7

Event Timeline

philkime added a project: Bug Report.Dec 2 2007, 1:15 AM
philkime set Version to 2.0.7.
philkime added a subscriber: philkime.
• werner added a subscriber: • werner.Dec 3 2007, 3:00 PM

Sorry, I can't replicate this with the current SVN version and the changelog
neither indicates that there was any change in this regard since 2.0.7.

However, while testing this I found and fixed another bug: If ssh support has
been enabled and you are trying to start the agent on a standard socket which
has a stale socket file, it deadlocks. That fix is in SVN 4635.

• werner added projects: gpgagent, gnupg.Dec 3 2007, 3:00 PM
philkime added a comment.Dec 3 2007, 8:32 PM

Hmm - which part couldn't you replicate? I think you're right about the ssh
functionality - I think that's perhaps what I hit. But isn't it confusing to
have gpg-agent report a socket number it doesn't use when started with
--use-standard-socket? Or maybe that's what you couldn't replicate? Here is a
typescript of what I see:

ls -al ~/.gnupg/S*

ls: /Users/username/.gnupg/S*: No such file or directory

gpg-agent --daemon --use-standard-socket

GPG_AGENT_INFO=/Users/philkime/.gnupg/S.gpg-agent:3026:1; export GPG_AGENT_INFO;

  1. gpg-agent --daemon --use-standard-socket
  2. ls -al ~/.gnupg/S*

srwxr-xr-x 1 philkime staff 0 Dec 3 11:16 /Users/username/.gnupg/S.gpg-agent

So, the agent says to set GPG_AGENT_INFO to socket with name
"S.gpg-agent:3026:1" but it doesn't exist because we used
"--use-standard-socket". It does create the correct socket for "--use
standard-socket". You're right that this doesn't break anything - I think I was
confusing the issue because of using ssh and the ssh bug you found. But it is
confusing as the GPG_AGENT_INFO socket the agent mentions is not used and
doesn't exist.

• werner added a comment.Mar 26 2008, 9:14 AM

Did you su to root and thus kept $HOMe at the old value? I do not understand
why you have "username" in the ls but "philkime" in the $HOME (which gpg-agent
uses to construct the name of the socket).

BTW, the name of the socket is the only the first part of GPG_AGENT_INFO;
delimited by the first colon.

philkime added a comment.Mar 26 2008, 9:13 PM

the username/philkime thing was just a typo, should both be "username". I can't
remember what the problem was any more, just that using "eval gpg-agent ...
didn't work properly and the agent couldn't be contacted when using
--use-standard-socket. I worked round it by just ignoring the STDOUT output of
gpg-agent when started and assuming that the socket is at ~/.gnupg/S.gpg-agent.
I think this issue can be closed.

• werner closed this task as Resolved.Dec 8 2008, 5:03 PM
• werner claimed this task.