GPG Agent discarding cache before ttl/max ttl

[Chip Senkbeil]

Hey folks!

Been using GPG for a couple of months to encrypt, sign, and authenticate and it's been great!

I'm trying to understand the scenarios in which the GPG agent will remove an entry from its cache.

I've got my default and max cache (both cache-ttl and cache-ttl-ssh) set to one day such that I don't need to enter my password upon accessing my mail on a timer, etc.

This works great until my laptop goes to sleep, I close the lid, etc. At that point, it appears to me that the agent tosses out the cache regardless of the length of time. This was not the case when I had GPG configured on a Mac, but when I switched to Fedora 30, I began having this problem.

It's a little frustrating because I frequently enter and exit a dock for work, closing and re-opening my laptop, as I dart between meetings, resulting in me needing to re-enter passwords through pinentry more frequently than I'd desire.

Is there some separate setting for GPG agent to discard its cache earlier than the ttl/max ttl settings? I've checked the GPG agent process and its still the same instance that had been running since I booted the laptop, so I don't believe it's the case where the agent is getting killed and restarted.

For reference, here's my gpg-agent.conf file:

    pinentry-program /usr/local/bin/my-pinentry-gui
    default-cache-ttl 604800
    max-cache-ttl 604800
    default-cache-ttl-ssh 604800
    max-cache-ttl-ssh 604800
    enable-ssh-support

I've got a custom bash script for the pinentry program that selects an appropriate pinentry process based on OS and capabilities (GUI/terminal).

And my gpg.conf file:

    # NOTE: Apparently does nothing with gpg2
    use-agent
    # When outputting certificates, view user IDs distinctly from keys:
    # NOTE: Since 2.0.10, seems to be obsolete as always used, but no harm in
    #       keeping it here
    fixed-list-mode

    # Long keyids are more collision-resistant than short keyids (it's trivial to
    # make a key with any desired short keyid)
    keyid-format 0xlong

    # When multiple digests are supported by all recipients, choose the strongest
    # one:
    personal-digest-preferences SHA512 SHA384 SHA256 SHA224

    # Preferences chosen for new keys should prioritize stronger algorithms:
    default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed

    # You should always know at a glance which User IDs gpg thinks are legitimately
    # bound to the keys in your keyring:
    verify-options show-uid-validity
    list-options show-uid-validity

    # When making an OpenPGP certification, use a stronger digest than the default
    # SHA1:
    cert-digest-algo SHA256

    # Prevent version string from appearing in your signatures/public keys
    no-emit-version

    # Never ask to insert smartcard if it wasn't already inserted to begin with
    # NOTE: Currently broken as the functionality appears to have been removed by
    #       commit 8c219602515ae1dba5bc0da31077852dab61809e when g10/gluecard.c
    #       was removed. From the latest commit, it seems like appropriate logic
    #       could be added back in agent/divert-scd.c in the main loop of
    #       ask_for_card function
    limit-card-insert-tries 1
    expert

~ Chip Senkbeil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20191015/22a46a72/attachment.sig>