Page MenuHome GnuPG
Create Task
Maniphest T2946

gpg-agent should be able to terminate when all its state expires
Open, NormalPublic
Actions

Description

Over on https://bugs.debian.org/853905 there's a (occasionally frustrating)
discussion about how to make gpg-agent minimize its presence on the host
machine. Some people really don't like having idle processes lying around.

It occurs to me that if the agent can be cleanly and automatically launched when
needed, and the startup cost is not high, then whenever it reaches a stateless
point, it can just terminate quietly and politely.

So the question is "what is stateless"?

In the current implementation, it's at least:

  • all cached passphrases have expired
  • no scdaemon is running (i'm happy to figure out scdaemon as well, but the

no-scdaemon case is easier to reason about)

  • no currently-open connections
  • updatestartuptty has never been called

Maybe we could even wait some fixed amount of time after this state has been
reached before we conclude we're not wanted, though that sounds like an extra
knob to twiddle.

Would that be sufficient to allow it to terminate quietly in some
configurations? I wouldn't want this to happen automatically, but it might be
an option --terminate-when-idle (or, if we want the extra knob,
--terminate-after-idle-seconds=N).

Details

External Link
https://bugs.debian.org/853905
Version
2.1.18

Event Timeline

dkg set Version to 2.1.18.Feb 6 2017, 9:19 PM
dkg added projects: Feature Request, gpgagent, Debian, gnupg.
dkg added a subscriber: dkg.
justus set External Link to https://bugs.debian.org/853905.Feb 7 2017, 11:04 AM
justus added a subscriber: justus.

One thing to look out for is a race condition between the agent deciding to shut
down, and a client trying to connect at that time, and that might lead to
intermittent failures. It may be doable correctly, but it is something to look
out for.

The other point being raised in the bug report about older daemons hanging
around over package upgrades should be discussed in a different bug. Yes,
shutting down the daemon when idle may work around this issue sometimes, but
clearly this is not a robust solution.

dkg added a comment.Feb 8 2017, 4:01 PM

I agree about that race condition being an important thing to consider, but i
think it's orthogonal to whether the process is self-terminating.

That is: we need to consider that race condition even in the case of deliberate
shutdown too, right?

Do we have a test case that involves two concurrent processes, one that tries to
stop the agent, and the other that tries to access it?

• werner added a subscriber: • werner.Feb 13 2017, 4:14 PM

The whole point of a daemon is that is idling in the background to wait for work.

A more useful feature would be to flush the passphrase cache when the user is
not anymore logged in. But for Debian this has already been done by --supervised.

marcus closed this task as Wontfix.Jul 13 2017, 1:27 AM
marcus claimed this task.
marcus added a subscriber: marcus.

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

dkg added a comment.Jul 14 2017, 12:38 PM

This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.

if gpg-agent has no state left, then being able to terminate cleanly would be a win (since it can be cheaply restarted to the same condition) .

I don't know where the "concerns were raised", but any additional information about those concerns would be welcome.

All of this code is difficult to implement correctly, and is difficult to test. But those arguments are not a great justification for not improving current behavior.

marcus reopened this task as Open.Jul 14 2017, 1:21 PM

Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

I have since reviewed the original discussion, and there is an interesting concern:

Over time, gpg even complains that "the agent is older than us", because
the uptime of the server will outlast multiple gpg upgrades. I assume
gpg will at some point just refuse to talk to the running agent?

However, this could also be solved by automatically restarting the gpg-agent in case such a version mismatch is detected, or by shutting down all gpg-agents after a package upgrade.

We can keep discussing this here, of course.

justus added a comment.Jul 14 2017, 1:52 PM

Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053

marcus removed marcus as the assignee of this task.Aug 4 2017, 8:52 PM
thesamesam added a subscriber: thesamesam.Sep 1 2023, 5:31 AM