Management of background services with systemd
gnupg at raf.org
Thu Mar 2 07:13:38 CET 2023
On Wed, Mar 01, 2023 at 09:24:35PM -0500, Michael Richardson <mcr at sandelman.ca> wrote:
> David Joaquín Shourabi Porcel <david at djsp.eu> wrote:
> > I am researching GnuPG for my employer. We will stick with the old
> > release series 2.2 at first, because few Linux distributions package
> > 2.3 or 2.4 yet. However, I'm studying newer versions and recent
> > developments to ease our future upgrades. In doing so, a question has
> > arisen: should background services like the agent not be managed with
> > systemd?
> Please no.
> It's bad enough as it is when you have multiple personalities you are trying
> to support (signing as me, vs signing code with an offline key)... having
> systemd (the userland one) popping off new copies would be horrible.
> Combined with SSH access to the machine, and the passphrase/pin popup shows
> up in the wrong place.
> (And many of us do not trust systemd and do not run it on important machines)
Having systemd control gpg-agent can be a huge problem
even with a single personality. If you want a user to
login via ssh to start an agent to temporarily store a
passphrase, and then the same user logs in separately
via ssh to make use of it, systemd treats them as
different user sessions, each with their own gpg-agent,
and the second one has no access to the passphrase
setup for it by the first one. Presumably, this isn't a
problem for most use cases, but it really spoiled
things for me.
More information about the Gnupg-users