9

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?

9

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.

  • 2
    I tried this and unfortunately gpgconf --reload gpg-agent does not make gpg-agent to forget passwords. – user124460 Sep 29 '15 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 '15 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 '15 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 '15 at 16:46
4

I use a simple:

echo RELOADAGENT | gpg-connect-agent

Work as a charm.

4

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.

  • Thanks for your answer - I might use this, if I do not find another solution to kill the cache. – Lars Jun 15 '13 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 '18 at 20:46
0

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/

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.