[PATCH] gpg-agent: Enable socket activation

[Shea Levy]

> 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.
>