GPG ignores default/max-cache-ttl?

woodape · 2016-12-07 07:11:35

The short of the problem I'm having is that I use the pass program with my gpg key to retrive my passwords for email many times a day, and despite my settings in my gpg-agent conf, I'm asked to unlock my gpg-key at seemingly random intervals throughout the day. I've configureed gpg-agent by setting the following in my .xinitrc:

eval "$(gpg-agent --daemon)"
export GPG_TTY=$(tty)

the following in my .bashrc

# Set SSH to use gpg-agent
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh"
fi
export GPG_TTY=$(tty)
# Refresh gpg-agent tty in case user switches into an X session
gpg-connect-agent updatestartuptty /bye >/dev/null

and the following in my ~/.gnupg/gpg-agent.conf:

enable-ssh-support
default-cache-ttl 25200
default-cache-ttl-ssh 25200
max-cache-ttl 25200
max-cache-ttl-ssh 25200

I use 'offlineimap' to collect my email, and have it configured to call 'pass' to get the password for my email accounts, which in turn calls on the gpg-agent to decrypt the password saved for the account. I have offlineimap in a wrapper script (which basically just checks if I'm online and does nothing if I'm not) which is called every 15 minutes by a 'systemd --user' timer.

The way I've been interpreting the 'default-cache-ttl' option in the gpg-agent conf is that the agent will keep the key unlocked if it has been used within the last 25200 seconds (7 days). Since my systemd timer calls on pass every 15 minutes, I should only have to enter the password to unlock the key pretty much once a session, and yet at seemingly random intervals through the day I'm asked to unlock it again. Its never something regular like every hour I'm asked, or only asked after 4 hours have passed, it does seem random to me.

Any ideas on how to make sure the agent is kept alive by my frequent calls to pass? Or am I misinterpreting some configuration?

EDIT:
I didn't realize, but to initialize the gpg-agent I had both the code above in the .xinitrc file as well as a the systemd --user service described in the Arch Wiki. I don't know if this is what was causing the issue, but if I'm not asked again for my password for the rest of the day I'll assume this was the issue and marked the thread solved.

EDIT2:
Apparently the above wasn't the issue. I was just asked for my gpg-key as offlineimap ran again. I'm out of ideas.

Last edited by woodape (2016-12-07 15:38:23)

losynix · 2016-12-09 17:37:31

Hi!
Did you solved your problem ? I'm having the same issue since a couple of days. I don't know where to look, everything is working fine separately but it fails when combined (pass and offlineimap).

woodape · 2016-12-09 18:15:08

Hi losynix, welcome to the forums! No I haven't solved the issue, but it's interesting that you have the same problem with the same setup. I think the next thing to try is to remove pass from the offlineimap config and replace it with a direct call to 'gpg --decrypt'. I'll give that a shot this evening and report tomorrow.

losynix · 2016-12-10 10:57:25

I'm not sure if pass is the issue here, I already made the test by changing the python command to get the pass:

def get_pass(account):
    # return check_output("pass " + account, shell=True).splitlines()[0]
    return check_output("gpg -d --quiet ~/.password-store/" + account + ".gpg", shell=True).splitlines()[0]

and it still doesn't work.
For me there are 2 suspects:
- pinentry: since it's last update I noticed that decrypting a file while the key isn't already loaded into the agent is way longer than before (I have to wait 3-4 seconds after entering the passphrase).
- offlineimap: running it for a single account (-a account) is fine but it fails when it syncs every accounts at the same time.

I would lean towards the second option.

woodape · 2016-12-10 11:09:24

What doesn't work in your above? I get an outright error trying to run your python function, mine is similar but I decode the output of the check_output:

        pass_store = os.path.join(os.path.expanduser("~"), ".password-store", "email", account + ".gpg")
	return subprocess.check_output(["gpg", "--decrypt", "-q", pass_store]).strip().decode('UTF-8')

I suppose you have a username in your pass-store, in which case you'd just tag the ".splitline()[0]" to the end of my command.

Mine runs just fine. It's only been a few hours running though, and I usually get asked to decrypt again after at least 5 hours

losynix · 2016-12-10 11:52:22

What I was saying is that it doesn't change anything if I get the password using pass or gpg. The problem I have is with offlineimap, when I run it for a single account it works fine, asking my passphrase if the key is not loaded. But when I run offlineimap for every account (6) it fails everytime. In this case if the key is not loaded, it asks my passphrase twice, success syncing two accounts, then fails with error "gpg: decryption failed: No secret key" for others.

NB: I did not specified anything in gpg.conf concerning cache-ttl
NB2: I noticed a segfault of gpg-agent in the logs but I'm unable to reproduce it

woodape · 2016-12-10 12:56:33

I'm not sure the issue that you're having is the same as mine, it sounds like you have an issue with your gpg-agent and not just the timeout configuration not being repsected.

losynix wrote:

NB: I did not specified anything in gpg.conf concerning cache-ttl

Was this a typo? The cace-ttl belongs in gpg-agent.conf, not gpg.conf

Do you set up the gpg-agent in the same way that I do in my first post? When you run "pgrep gpg-agent" do you get a PID back? If you try and decrypt the pass-store "account.gpg" file manually do you get any errors?

losynix · 2016-12-10 15:50:53

It was indeed a typo sorry. Yes my gpg-agent starts after login and decrypting manually every password works fine too.

I think I got the source of the problem, it appears that gpg-agent is having trouble managing multiple decryption requests at the same time. In offlineimap.conf I changed maxsyncaccounts = 6 to 1 so accounts are synced one by one instead of simultaneously and it seems to work now.

You're right my problem is not the same as yours, I actually run offlineimap continuously (with the autorefresh option, offlineimap never exits), passwords are decrypted once at start and that's it.
This is in fact not a cache-ttl issue, I just posted here because you mentionned pass and offlineimap but our problems are different afterall. Any way I hope you'll fix yours !

Last edited by losynix (2016-12-10 16:00:47)

woodape · 2016-12-10 20:34:36

Thanks losynix.

Update: I had replaced the call to pass with a direct call to "gpg --decrypt --quiet" and after about 8 hours - with offlineimap run every 15 minutes - I was asked for my password again. Back to square one.

e.sovetkin · 2016-12-11 11:37:13

losynix wrote:

I think I got the source of the problem, it appears that gpg-agent is having trouble managing multiple decryption requests at the same time. In offlineimap.conf I changed maxsyncaccounts = 6 to 1 so accounts are synced one by one instead tof simultaneously and it seems to work now.

It seems to be true. I have the same problem with multiple requests being called from crontab.

Maybe it is worth to report it to gnupg upstream? Or is it a known issue?

UPD: I have wrote a small script, that reproduces the problem. It uses parallel. Can someone confirm it here?

#!/bin/bash

recipient = "$1"

dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 1.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 2.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 3.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 4.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 5.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 6.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 7.gpg
dd if=/dev/random count=1 | gpg -e -r ${recipient} -o 8.gpg


call () {
    gpg -d $1.gpg &> /dev/null
    echo $1.gpg
}

export -f call

arg=()
arg+=("1")
arg+=("2")
arg+=("3")
arg+=("4")
arg+=("5")
arg+=("6")
arg+=("7")
arg+=("8")

echo ${arg}

parallel -j8 call ::: ${arg[@]}

Last edited by e.sovetkin (2016-12-11 13:08:08)

woodape · 2016-12-11 19:15:53

Hi e.sovetkin, I used a slightly simpler script to recreate the same thing:

echo "test" | gpg -e -r MYID -o test.gpg
for i in {1..8} ; do 
    gpg -d test.gpg &
done

Sure enough calling on gpg to decrypt in quick succession has it call the pinentry program to unlock the key again. I suppose gpg locks the secret key when its decrypting something, so it becomes unavailable if the next call comes too quickly. This sounds like a feature to me, not a bug.

However, as far as I can tell, offlineimap doesn't decrypt the password multiple times regardless of the maxconnections value. I put a print statement in my get_pass function, print("Now getting the password"), and I see this message only once when running "offlineimap -u quiet", suggesting the function is called only once even with a maxconnections = 15. I tried putting a similar line that appends to a file and see the same result, one call to get_pass and therefore to gpg --decrypt per account. Each of my accounts has at least a dozen folders so the calls to the accounts is separated by at least 10 seconds, plenty of time for the agent to be refreshed.

e.sovetkin · 2016-12-12 08:43:20

I agree the script you provided is more elegant and shows the same behaviour.

I don't use offlineimap, but have different scripts in crontab which are sometimes being called simultaneously which causes the described behaviour.

However I find this "feature" quite disturbing and I haven't found any references to this in recent release notes/news.

Can you provide some justification, when this feature may be useful. Why should the secret key become unavailable during decryption (for secret key it is a read-only operation)?

Last edited by e.sovetkin (2016-12-12 09:14:38)

woodape · 2016-12-12 09:44:28

I'm no cryptography expert so I can't readily provide a solid justification. It could very well be buggy code and not the intended behavior. My amateur understanding of what's going on under the hood however, makes me think that this could be a way to prevent a brute force attack to get at the secret key. If you think it is a bug maybe you should consider filing a bug report as you suggested earlier.

However, I opened this thread because of an issue I was having with gpg and offlineimap. As I said in my previous post, offlineimap doesn't call the password function multiple times regardless of the number of maxconnections per account, and so this "bug/feature" would only explain my issue if the accounts were called to sync in rapid succession - which given their size and my low number of maxconnections is never less than 10 seconds, so not rapid at all.

In any case, I'm going to prepend:

from time import sleep
sleep(2)

to my "get_pass" function so that just in case some weirdness is going on that causes the accounts to be rapidly called in succession, there will be at lest 2 seconds before the last gpg call. Offlineimap only attempts account logins serially, so the password for the second account is never called before the password for the first account has been returned either successfully or in error.

losynix if you're still following this thread I suggest trying out the same. Decreasing your maxconnections likely only increased the amount of time between account access, this may be a better solution given your use case.

I'm putting that code in there now, and if by tomorrow I haven't been asked for my password again, I'll consider this "bug/feature" to be at least the bug with my setup and mark this solved.

EDIT:
Was asked for my password again after 7 hours, even with the added delay in the password function.

Last edited by woodape (2016-12-13 13:10:07)

shioyama · 2017-07-20 23:51:24

Hi everyone,

I'm encountering the same problem but with isync (mbsync) and gpg/pass. I sync three accounts and get the pinentry popup repeatedly, on top of which entering my passphrase doesn't seem to work so that I have to keep entering over and over until finally it seems to accept the passphrase. Very strange... but it's driving me a bit crazy.

There is no maxsyncaccounts config, so that one doesn't seem to be an option. I've tried adding some sleeps in there to limited success, but nothing really seems to stick.

shioyama · 2017-07-20 23:54:42

Hmm... ran the test script above and I don't get pinentry. So maybe something else is the culprit in my case.

bigodel · 2021-10-03 04:36:14

hey, i created an account just to comment on here.

was this really not resolved? has no one come up with a solution? i'm trying out using different pinentry programs to see if that helps, but no luck yet...

i'm on a similar setup to OP's, but i'm using mbsync instead of offlineimap and i have also tried replacing the pass calls to gpg calls, which basically rules out pass as the culprit. i'm really hoping on getting some insight into this, because on one side i am constantly and randomly bothered by pinentry asking me for my password, even though i have used it in the last X amount of TTL time that i set up; and on the other i just set gpg-agent's time to live to some absurd value like an year so as not to bothered by it (still in trial, though, even this might not work as intended...). i must also note that i have not started the agent manually, in my init files, and i rely on the default that Arch Linux currently starts, but in the Wiki it says that configuration is still done on ~/.config/gnupg/gpg-agent.conf, so i'm relying on them on this particular matter.

seth · 2021-10-03 07:51:58

randomly bothered by pinentry asking me for my password

gpg might restart or reload (via SIGHUP) - there're quite some stackexchange and superuser threads on this so I guess that's a thing…

Eruvaer · 2023-05-18 14:30:19

woodape wrote:

[...] and the following in my ~/.gnupg/gpg-agent.conf:
enable-ssh-support
default-cache-ttl 25200
default-cache-ttl-ssh 25200
max-cache-ttl 25200
max-cache-ttl-ssh 25200
[...] The way I've been interpreting the 'default-cache-ttl' option in the gpg-agent conf is that the agent will keep the key unlocked if it has been used within the last 25200 seconds (7 days). [...]

woodape wrote:

[...] and after about 8 hours - with offlineimap run every 15 minutes - I was asked for my password again. Back to square one.

woodape wrote:

[...] Was asked for my password again after 7 hours, even with the added delay in the password function.

[bold mine]

Am I missing something or did just no one so far notice that 25200 seconds are not 7 days, but 7 hours? As such, it seems to me that gpg-agent is working just fine and the only problem is that the TTL limits in gpg-agent.conf should have been set to 604800 seconds (i.e., 86400 * 7) to achieve the intended outcome.

PS I realize it's an old thread, but given that it has already been necroed twice, I figured it might still be useful to someone...

Arch Linux

#1 2016-12-07 07:11:35

GPG ignores default/max-cache-ttl?

#2 2016-12-09 17:37:31

Re: GPG ignores default/max-cache-ttl?

#3 2016-12-09 18:15:08

Re: GPG ignores default/max-cache-ttl?

#4 2016-12-10 10:57:25

Re: GPG ignores default/max-cache-ttl?

#5 2016-12-10 11:09:24

Re: GPG ignores default/max-cache-ttl?

#6 2016-12-10 11:52:22

Re: GPG ignores default/max-cache-ttl?

#7 2016-12-10 12:56:33

Re: GPG ignores default/max-cache-ttl?

#8 2016-12-10 15:50:53

Re: GPG ignores default/max-cache-ttl?

#9 2016-12-10 20:34:36

Re: GPG ignores default/max-cache-ttl?

#10 2016-12-11 11:37:13

Re: GPG ignores default/max-cache-ttl?

#11 2016-12-11 19:15:53

Re: GPG ignores default/max-cache-ttl?

#12 2016-12-12 08:43:20

Re: GPG ignores default/max-cache-ttl?

#13 2016-12-12 09:44:28

Re: GPG ignores default/max-cache-ttl?

#14 2017-07-20 23:51:24

Re: GPG ignores default/max-cache-ttl?

#15 2017-07-20 23:54:42

Re: GPG ignores default/max-cache-ttl?

#16 2021-10-03 04:36:14

Re: GPG ignores default/max-cache-ttl?

#17 2021-10-03 07:51:58

Re: GPG ignores default/max-cache-ttl?

#18 2023-05-18 14:30:19

Re: GPG ignores default/max-cache-ttl?

Board footer