gpg-agent incorrectly detects currently running daemons

[Roy Liu]

The Xsession.d/90gpg-agent script doesn't seem to be correct. It sources "$PID_FILE", whose contents contain something like "GPG_AGENT_INFO=/tmp/gpg-erNjuZ/S.gpg-agent:6363:1". Unfortunately, GPG_AGENT_INFO isn't used anywhere later in the script and is not visible to subsequent gpg-agent invocations. I believe that the correct behavior is to export it, so that the sourcing of "$PID_FILE" isn't for naught.

[nic-stange (nic-stange)]

Since gpg-agent is being run through the $STARTUP chain, sourcing that $PID_FILE seems unnecessary if gpg-agent gets actually invoked by this script. If I get things correctly, this sourcing part of the script is only intended to recover access to a (leftover?) gpg-agent that is already running when this script is entered.

Maybe your problem is related to this one instead:
https://bugs.launchpad.net/ubuntu/+source/gnupg2/+bug/743268

I applied that patch given there and everything works fine.

[Roy Liu (royliu)]

I just posted an explanation on the thread of the related bug report.

[Rolf Leggewie (r0lf)]

this is only a problem if the setting of $GPG_AGENT_INFO differ between $PID_FILE and what's already in the environment variable prior to sourcing $PID_FILE or am I overlooking something? does this ever happen?

[Roy Liu (royliu)]

A snippet from 90gpg-agent reads like this.

   # Invoking gpg-agent with no arguments exits successfully if the agent
   # is already running as pointed by $GPG_AGENT_INFO
   if ! $GPGAGENT 2>/dev/null; then
       STARTUP="$GPGAGENT --daemon --sh --write-env-file=$PID_FILE $STARTUP"
   fi

That's why we need to export GPG_AGENT_INFO; otherwise, the code doesn't even do what it says it does.