Controlling the lifetime of keys unlocked in a GnuPG agent

Question

For (slightly) increased security, I would like to have better control of the lifetime of any unlocked keys, depending on the task being performed. Ideally, I would start an interactive sub-shell, do any tasks involving secrets, then have all unlocked keys be cleared automatically when the sub-shell exits.

I know that one can manually clear cached passphrases using gpg-connect-agent, but AFAIK that requires each key to be specified explicitly. Another option would be to set a sort cache expiry time using the --default-cache-ttl or --max-cache-ttl options for gpg-agent; but generally that means either setting a long TTL, or being asked for the same passphrase more than once.

I seem to remember that a long time ago it was possible to specify an alternative gpg-agent socket path and basically start an independent session, but that does not seem to be possible any more; newer versions seem to use a fixed path that cannot change.

So, what am I missing? Is there a way to achieve what I want?

Answer 1

While I do not have a full solution, I did find a workaround:

By using an alternate home directory for GnuPG via the --homedir parameter or the GNUPGHOME environment variable, one can force GnuPG to use a different set of key storage files and associated agent socket paths. With that in mind, I can start a shell inside a new gpg-agent session:

gpg-agent \
    --homedir /my/other/keys \
    --default-cache-ttl 86400 \
    --max-cache-ttl 86400 \
    --daemon \
    \
    /bin/bash

Any entered passphrases will either expire if the specified TTL passes (one day in this example), or will be "forgotten" when the new shell exits, as that will cause the parent gpg-agent instance to self-terminate.

The reason I do not consider this a full solution is that it forces the use of a separate keyring. However, that works perfectly for my specific use case and, therefore, I did not investigate further.

It may be possible to achieve the full effect of independent sessions for the same keyring by having symlinks to the default GnuPG keyring, provided enough care is taken w.r.t. maintaining any locking between different gpg-agent instances. I'll leave that as an exercise to the reader...