[PATCH] dirmngr: implement --supervised command (for systemd, etc)

[Werner Koch]

On Thu, 11 Aug 2016 22:47, dkg at fifthhorseman.net said:

> Well, there is no general "gnupg log" that i'm aware of -- but i'm fine
> with re-enabling the log-file directive in --supervised mode if you

My advise has always been to put 

  log-file socket:///home/user/.gnupg/S.log

into the conf files and use watchgnupg to read or log them.  In fact
that is what kmail does with its kwatchgnupg.

> ssh-agent).  But in the system supervision case it's actually still the
> same gpg-agent that's running, not an imposter.  it's just be started up
> automatically without exercising any of the auto-spawning code.

How do you convey the envvars to gpg-agent?  What systemd does is
different from what gpg will do; for example the default tty, DISPLAY,
and locale may be different.  gpg will also pass --homedir to the
invocation of gpg-agent if gpg has been started this way.

> There is considerably more code in dirmngr that is only for the purposes
> of supporting one specific OS (Windows) than there is in the patchset
> i've proposed.

Actually we are not using dirmngr as a system service on Windows for
some years.  Thus most of this code is subject to removal.

>  0) do not start the daemon unless something the user does actively
>     needs it.

That is already accomplished by gnupg itself.

>  1) do not run multiple instances of the daemon for any given user.

Ditto.

>  2) cleanly and promptly terminate the daemon when the user has
>     no more running sessions on the machine.

For dirmngr this is not a good idea because we plan to add background
tasks (parcimonie).

For gpg-agent there valid use cases to keep on running gpg-agent even
after all user sessions are closed.  For example a server is using a
smartcard to autheniticate connections done via cron.  Terminating the
gpg-agent and thus gpg-agent would reset the smartcard and require the
operator to open a session to enter the PIN again.

> Recent versions of gnupg support desiderata 0 and 1 fairly well out of
> the box, but i've seen no concrete proposals for how to deal with 2, and

A simple solution would be to "gpgconf --reload gpg-agent" after logout
of any session.  This will flush the caches and thus no sensitive
information is held by the agent.  This might be a bit annoying for
other sessions using gpg-agent becuase they need to re-enter their
passphrase, but I guess people can live with that.  Or just kill the
gpg-agent at session end, it will be restarted anyway as needed.

For killing I added a feature to tell the number of active connections
to gpg-agent, so that a logout script can gracefully kill gpg-agent.
But even that is not required because a single SIGTERM will delay
termination until all connections are close.

Another option is that gpg-agent can be changed to terminate itself some
time after all cache entries are expired.

> some legitimate complaints about it (see an earlier Subject: in this
> thread, which came from debian developer Ian Jackson: "Beware of
> leftover gpg-agent processes").

One gpg-agent process per user, unless several have been started from
different home directories.  In fact gpg-agent has a self-check to make
sure that only one instance is running for a given homedir (technically
for a given socket).

BTW, I wish Ian would finally apply the Tor patches to adns after more
than one year of asking him.  It is annoying that we have full Tor
support only on Windows.

> environment.  This kind of system integration allows for the creation of
> simple quick overview tools of machine state (e.g. "systemctl --user
> status"), standardized logging (e.g. "journalctl --user -u gpg-agent"),

<scnr>Sounds like Windows and not like Unix</>

> eh?  It sounds to me like you're aware of some complaint or bug report
> i'm unware of.  Could you explain more, or point me to a specific
> example, please?  I've been running systemd for quite some time and i've

See the recent LWN article about systemd terminating all processes  at
session close including nohup'ed processes.

> Certainly, you can configure systemd to act as a "watchdog" and have it
> kill processes that don't report regularly to a dbus interface,

GnuPG does not use dbus.  Long ago I considered to add support for this
but after checking all the dependencies and code required for dbus I
figured that this is not a good idea and could only be added using an
external helper.

What your proposed change won't solve is the ssh-agent support.  Well
gpg-agent would be started by ssh as needed - cool.  But the also
important point on how to convey the envvars to gpg-agent is not solved -
this requires changes to the ssh-agent protocol and code changes to ssh,
proper.  Now if those changes are anyway required, the autostarting can
be added as well.



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf  <https://openpgp-conf.org> */