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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to