[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