31

I am using gpg-agent 2.0.17 with gpg 1.4.11 on ubuntu 12.04 and the Enigmail Addon for Thunderbird. When opening an encrypted email, Enigmail invokes gpg-agent with the associated pinentry program and asks for the password. I then have the option to set the lifetime for the cached password, usually set to end of the session.

Since I rarely shutdown or logout of my session, I would like to force gpg-agent to forget all cached passwords upon locking the session. I've searched for a way to do so and the man-page of gpg-agent states, that a -SIGHUP will flush all passwords - however, contrary to the manpage, the cached passwords are not forgotten.

Any ideas on how to force gpg-agent to forget the passwords?

1
  • See this answer on stackoverflow. The key is to use options like --max-cache-ttl as max-cache-ttl without the leading -- and to use gpgconf --reload to reload the configuration of your ~/.gnupg/gpg-agent.conf.
    – Amin NAIRI
    May 17, 2021 at 9:10

7 Answers 7

8

TTL for cache passwords is controlled by gpg-agent's options:

--default-cache-ttl n
  Set the time a cache entry is valid to n seconds.  The default is 600 seconds.

--max-cache-ttl n
  Set  the  maximum time a cache entry is valid to n seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

As per a way to control this on-demand, if you are able to trigger a command upon locking your screen, using keychain to handle gpg-agent could be used to execute

keychain --clear --agents gpg

which would kill all managed instances of gpg-agent. But then, you should have a way to execute keychain --agents gpg --eval $gpg upon unlocking your screen. Maybe too much hassle.

2
  • Thanks for your answer - I might use this, if I do not find another solution to kill the cache.
    – Lars
    Jun 15, 2013 at 18:42
  • Where can you set gpg-agent's options, or where's the default location, ~/.gnupg? There's no gpg*.conf files in my home (no gpg-agent.conf anywhere actually) so I guess everything goes to defaults
    – Xen2050
    Jan 5, 2018 at 20:46
27

gpgconf --reload gpg-agent is one way to force the agent to forget passwords it has cached in memory. Currently (gpg 2.0-2.1) this is [almost] equivalent to pkill -HUP gpg-agent. I say "almost equivalent" since you could, in theory, have more than one agent running and the pkill will try to deliver SIGHUP to all of them.

7
  • 5
    I tried this and unfortunately gpgconf --reload gpg-agent does not make gpg-agent to forget passwords.
    – user124460
    Sep 29, 2015 at 14:34
  • @Bruno: It works for me with various versions of gnupg 2.0.* and 2.1.*. You may have to do some debugging to ensure your invocation of gpgconf is talking to the gpg-agent being used to store your password. Beware of agent interposers such as gnome-keyring-daemon - I suspect that does not work with gpgconf.
    – Juan
    Sep 30, 2015 at 16:29
  • @Bruno: try this: kill all instances of gpg-agent; run gpg-agent --daemon sh; echo yadamo > /tmp/foo ; gpg --symmetric --output /tmp/foo.encrypted /tmp/foo (you will be prompted for a passphrase to encrypt the file). At that point /tmp/test.encrypted should be an encrypted file that can only be unencrypted with the passphrase you specified. If you then run gpg --decrypt /tmp/foo.encrypted, you should get "yadamo". Then run gpgconf --reload gpg-agent and try the decrypt again. You should be prompted for the passphrase that has now been forced to be forgotten by the agent.
    – Juan
    Sep 30, 2015 at 16:36
  • @Bruno: Basically, I believe gpgconf --reload gpg-agent tries to send SIGHUP to the gpg-agent PID (just as if you used kill -HUP <pid> or kill -1 <pid>). If gpgconf can't deliver SIGHUP to the agent for whatever reason (e.g., can't find the right PID) or the "agent" is not really gpg-agent and doesn't know that SIGHUP means to unload cached secrets, then the gpgconf reload won't work. If you figure out what's going on in your case, let us know.
    – Juan
    Sep 30, 2015 at 16:46
  • 1
    I tested this with GnuPG 2.2.19, with only one gpg-agent running and that is not making gpg-agent forget the password (Solus 4.1).
    – Anthon
    Mar 14, 2020 at 8:09
15

I use a simple:

echo RELOADAGENT | gpg-connect-agent

Work as a charm.

--

Edited: tested with Debian 10, gpg 2.2.12, libgcrypt 1.8.4

3
  • 2
    I tested this with GnuPG 2.2.19, with only one gpg-agent running and that is not making gpg-agent forget the password (Solus 4.1).
    – Anthon
    Mar 14, 2020 at 8:13
  • Dear @Anthon, after your comment I went on to test the solution (and maybe provide an update), but as of today Debian 10 uses gpg 2.2.12, and in that version this solution still works flawlessly. As Debian moves forward and this stops working, I'll update as needed. Thanks!
    – DrBeco
    Mar 25, 2020 at 18:48
  • I understand that this one will also reload the agent, but is it possible to reload custom config file from /another_path/gpg-config.conf
    – MaXi32
    Aug 21, 2020 at 19:22
2

None of the other answers would work for me on GnuPG 2.2.19 (Solus 4.1, Nitrokey Smart, gnuk token for storage). I had made sure only one gpg-agent is running, and when appropriate it would respond with OK.
What I ended up doing is:

killall gpg-agent

You should always test, if the above really has made the passwords forgotten by decrypting some encrypted file (gpg -d < somefile.gpg)

1

This is what worked for me in clearing a single password (i.e. passphrase) - run from the terminal - if you want to clear them all then https://superuser.com/a/1269901/457084 works:

gpg-connect-agent "clear_passphrase --mode=normal <cacheid>" /bye

where <cacheid> is most likely the keygrip available if you execute: gpg --list-keys --with-keygrip:

<path to pubring.kbx>
------------------------------------------------
pub   rsa2048 2017-12-11 [SC] [expires: 2019-12-11]
    <keyid>
    Keygrip = <keygrip>
uid          `<email>

With a bit of help from https://web.archive.org/web/20180528210236/https://demu.red/blog/2016/06/how-to-check-if-your-gpg-key-is-in-cache/

1
  • gpg: invalid option "--with-keygrip" (apparently gpg 2.0 on centos 7.x doesn't have it).
    – jhfrontz
    Oct 18, 2018 at 15:50
0

gpg-connect-agent reloadagent /bye

1
  • 2
    I tested this with GnuPG 2.2.19, with only one gpg-agent running and that is not making gpg-agent forget the password (Solus 4.1).
    – Anthon
    Mar 14, 2020 at 8:12
0

To use this in a bashrc function, I want to have output suppressed and not leave open shells, so with thanks to @wisbucky and @DrBeco :

gpg-connect-agent reloadagent /bye >/dev/null

Works on Fedora 39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .