[PATCH] gpg-agent: Enable socket activation

Shea Levy shea at shealevy.com
Fri Nov 21 05:19:00 CET 2014

> On Nov 20, 2014, at 1:59 PM, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 20 Nov 2014 14:20, shea at shealevy.com said:
>> Hm, I don’t understand this reasoning. Why is it bad to use
>> non-portable methods in a completely optional feature? I’m not
> For maintenance reasons and to reduce code complexity.

Fair enough, but that has nothing to do with portability :)

>> If all portable software avoided optional use of non-portable
>> functionality, I doubt any functionality would gain enough prominence
>> to become established.
> True if that would solve any real problem.  <rant>systemd is the
> Windowization of Unix and such the opposite of portable and modularized
> software.  It is sad to see how WindowsNT moved over the last 15 years
> towards a system more similar to Unix while Linux as the spearhead of
> the Unix standardization is splitting up into the non-interoperable Unix
> world we had reached 25 years ago.  Time to reconsider FreeBSD</>

Hey, I dislike a lot of what systemd is doing/has done to the Linux community too. But just because one of the main implementors of socket activation has some bad qualities doesn’t mean socket activation itself isn’t a useful tool :) I’ve pointed out the specific problems socket activation solves, and as I’ve said I’ve hit some of these problems in practice.

>> Not everyone has the luxury of a personal single-user machine, and
> You shall not use private keys on a multi-user machine.

Some people have no other option, and while of course it’s not ideal I’d prefer that they have access to some measure of privacy (as I’m sure you would too).

>> 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
> --no-detach already exists but it is mostly useless.  Yes we can
> probably add an option to run without a fork but I see no use case for
> that except for starting gpg-agent from inittab (or whatever you guys do
> on your not-anymore-Unix boxes these days).

Yes, starting it from inittab (or the user-level version of it) is exactly the use case.

> The main point is: gpg-agent shall be started on demand and not by any
> session control daemon.

If that is final then I guess there’s nothing more I can say.

>> benefits of having the daemon manage lifetime easier in that scenario.
> BTW, having a session logoff script remove the socket file is an easy
> way to shutdown gpg-agent:
>  4 - 19:57:49 gpg-agent[563]: can't connect my own socket: IPC connect call failed
>  4 - 19:57:49 gpg-agent[563]: this process is useless - shutting down
>  4 - 19:57:51 gpg-agent[563]: gpg-agent (GnuPG) 2.1.1-beta19 stopped
> and by using rm(1) this is race free.

This is not race free, some process still running after the logoff script can try to connect, see there’s no socket, and spawn a new agent.

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

More information about the Gnupg-devel mailing list