[PATCH] dirmngr: implement --supervised command (for systemd, etc)
wk at gnupg.org
Fri Aug 12 12:12:57 CEST 2016
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
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.
> 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
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
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.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* Join us at OpenPGP.conf <https://openpgp-conf.org> */
More information about the Gnupg-devel