[PATCH] gpg-agent: Enable socket activation

shea at shealevy.com shea at shealevy.com
Thu Nov 20 01:19:29 CET 2014


Hi Werner,

There are three issues that using externally-managed socket activation 
can bypass:

* With socket activation, external programs talking to the agent simply 
need to try to connect to the socket. With on-demand activation as it 
currently exists, they must try to connect and then spawn gpg-agent and 
try again. This is more complicated and requires the external program to 
run with gpg-agent in PATH or with a hard-coded path to the agent.
* With on-demand activation as it currently exists, two agent-using 
programs spawned simultaneously may step on each other creating the 
socket (this can theoretically be bypassed with file locks, perhaps this 
is already done in which case this is a non-issue).
* User-level daemon managers like systemd --user and launchd know when 
the user has logged out, and thus can kill the running agent and refuse 
to spawn new instances upon new connections. With on-demand activations 
as it currently exists, there's no easy way to kill the daemon on log 
out, and even if you add a custom service that runs gpg-connect-agent 
KILLAGENT on logout there is a race possible where another process tries 
to connect after the kill goes through. I've actually hit this issue.

~Shea

On 2014-11-19 02:59, Werner Koch wrote:
> On Wed, 19 Nov 2014 00:05, shea at shealevy.com said:
>
>> as the agent listening socket. This allows service managers like
>> launchd or systemd to enable on-demand activation of gpg-agent 
>> without
>> potential races at initialization or termination time.
>
> gpg-agent is started on demand by the modules which need gpg-agent.
> There is no need for any init service to start gpg-agent in advance.
> Even 2.0 may be build or runtime configured to be started on demand.
>
>
> Shalom-Salam,
>
>    Werner




More information about the Gnupg-devel mailing list