[PATCH] gpg-agent: Enable socket activation

[Shea Levy]

Hi Werner,

> On Nov 20, 2014, at 6:31 AM, Werner Koch <wk at gnupg.org> wrote:
> 
> On Thu, 20 Nov 2014 01:19, shea at shealevy.com said:
> 
>> * With socket activation, external programs talking to the agent
>> simply need to try to connect to the socket. With on-demand activation
> 
> That would a very different program than we have now.  The Hurd calls
> this a translator and it is a nice technique.  However, neither systemd
> nor translators are established and portable methods and thus should be
> avoided by portable software.  But please save us a systemd discussion.
> 

Hm, I don’t understand this reasoning. Why is it bad to use non-portable methods in a completely optional feature? I’m not suggesting we abandon the current on-demand logic. And FWIW, both OS X and Linux have existing support for socket activation (I’m pretty sure systemd —user can be used even on hosts that don’t use systemd as init), and it is very easy to write a socket-activating wrapper around a program in POSIX C.

If all portable software avoided optional use of non-portable functionality, I doubt any functionality would gain enough prominence to become established.

> Actually, we do this for years on Windows and it works very reliable.
> 
>> socket (this can theoretically be bypassed with file locks, perhaps
>> this is already done in which case this is a non-issue).
> 
> Sure that is done.  In addition gpg-agent checks that its socket has not
> been reused by another aganet and termintes itself in this case.
> 

Ah, I’m glad to know :)

>> * User-level daemon managers like systemd --user and launchd know when
>> the user has logged out, and thus can kill the running agent and
> 
> Valid point.  Hwoever I don't see a problem to not terminate the
> gpg-agent on logout.  After all most mechines today are single user and
> the agent is supposed to run on your own desktop and not on a remote
> machine.  What one should put into the ~/.xession at exit is 
> 
>  gpgconf --reload gpg-agent
> 
> (or code to send a HUP) to flush the caches.  This should also be done
> before the system hibernates.
> 

Not everyone has the luxury of a personal single-user machine, and it’s IMO bad etiquette to leave software running unnecessarily after your session. But fair enough.

>> 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
> 
> Well that would be hard to avoid unless one accespts a stale lock file.

Or, in the case where the socket is managed by a session-aware daemon, it can just refuse to spawn a new instance :)

> 
> 
> Salam-Shalom,
> 
>   Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 

If socket activation isn’t an option, can we at least have a flag to not fork and set a new session? At least we still get some of the benefits of having the daemon manage lifetime easier in that scenario.

~Shea