Not working with mbsync/mutt/pass

[StarTroop]

Last year (around October) I had set up neomutt with the mutt wizard tool. Mbsync (aka isync) was set up to download my mail, using a systemd service and timer at 30 minute intervals and 2 minutes after login. This worked initially, but sometime near the end of 2020 I started to get prompts to enter my password at the first activation of mbsync (whether it was manually activated, or through the systemd service,) both after login and once the cache had timed out. Mbsync (and all other mail-related sync programs) all use Pass to pull the password, but I've never been clear on how exactly pass and gnupg integrate.

I've been researching this issue off and on since then, have tried a few configurations, but I can't nail down where the problem lies. Currently, I'm back to having it configured exactly as the readme explains. I'm using Arch, the pam-gnupg package from the AUR.
I have:

auth     optional  pam_gnupg.so
session  optional  pam_gnupg.so

at the end of my system-local-login.
I have:

allow-preset-passphrase
default-cache-ttl 604800
max-cache-ttl 604800

in my ~/.gnupg/gpg-agent.conf.
I have my correct keygrip in my ~/.pam-gnupg. I've confirmed that I made no typos anywhere. My user password and gnupg password are identical. I don't use any DM, so I log in from tty and automatically startx into an xfce/i3 environment. I don't believe I've seen any errors relating to pam-gnupg in journald logs.

I'm just not sure where the issue lies, and therefore have reached the limit of my ability to troubleshoot it. The only other detail I have is that IIRC the issue started occurring after a pam-gnupg update, but it's been so long that I can't be entirely certain of that, but that's why I'm posting this issue here first.

[cruegge]

End of last year was probably the 0.2 update on 31 October. That did include a somewhat large structural change where I moved parts of the code to a helper binary due to paranoia regarding fork()ing a potentially multi-threaded process.

Can you add the debug option to the pam_gnupg.so lines and check what messages appear in the journal?

[StarTroop]

Here's the output of journalctl -b -g pam_gnupg:

-- Journal begins at Sun 2020-11-08 21:09:20 EST, ends at Tue 2021-06-08 18:42:51 EDT. --
Jun 08 18:40:27 t420 login[361]: pam_gnupg(login:auth): stored passphrase
Jun 08 18:40:27 t420 kernel: audit: type=1100 audit(1623192027.134:51): pid=361 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnupg acct="alex" exe="/usr/bin/#" hostname=t420 addr=? terminal=/dev/tty1 res=success'
Jun 08 18:40:27 t420 audit[361]: USER_AUTH pid=361 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnupg acct="alex" exe="/usr/bin/#" hostname=t420 addr=? terminal=/dev/tty1 res=success'
Jun 08 18:40:27 t420 login[361]: pam_gnupg(login:setcred): helper terminated with exit code 1
Jun 08 18:40:27 t420 login[361]: pam_gnupg(login:setcred): presetting failed, retaining passphrase
Jun 08 18:40:27 t420 audit[361]: USER_START pid=361 uid=0 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_limits,pam_unix,pam_permit,pam_mail,pam_systemd,pam_env,pam_gnupg acct="alex" exe="/usr/bin/#" hostname=t420 addr=? terminal=/dev/tty1 res=success'
Jun 08 18:40:27 t420 login[361]: pam_gnupg(login:session): presetting passphrase succeeded, cleaning up
Jun 08 18:40:27 t420 login[361]: pam_gnupg(login:setcred): unable to obtain stored passphrase

Not sure what to make of it but apparently something is wrong.

[jemadux]

never confgure it do make it work at login ... i should always run mbsync when i login ...

[kronikpillow]

2022 ... autor of #36 ... back on arch, still same issue, gpg keys don't get unlocked until i run mbsync

[psaikido]

I'm seeing the same behaviour as StarTroop has detailed.

[Seme4eg]

same here

[cruegge]

I don't really have an idea what might cause this. To take a wild guess, can you check that the agent is actually running right after login, before running mbsync manually or via timer? Also, does it listen on the correct sockets? ss -xlp | grep gpg-agent should show it listening at least on /run/user/<PID>/gnupg/S.gpg-agent. Finally, does gpg-connect-agent 'getinfo pid' 'keyinfo --list' /bye show the same PID as the previous command on the first output line, and a 1 in column 7 (before the P) for your keygrip?

[Seme4eg]

the agent is actually running right after login, before running mbsync manually or via timer

- yes

does it listen on the correct sockets

- yes

Finally, does gpg-connect-agent 'getinfo pid' 'keyinfo --list' /bye show the same PID

- yes

and a 1 in column 7 (before the P) for your keygrip

- no, but it appears after i first unlock gpg key

[cruegge]

If you're okay with having your password in hex encoding written to a temporary log file, can you try adding the lines

debug-level 1
log-file agent.log

to you gpg-agent.conf? The file should be created in your home directory. Do not post the content here!

Does the file contain a line like preset_passphrase <keygrip> -1 <hex-encoded password>, and an OK in the next line?

[Seme4eg]

do i need pam-gnump installed and set up before i check what you asked or no?

[cruegge]

Yes, the preset_passphrase command is sent by pam-gnupg to the agent on login. I'm trying to check whether the command arrives at the agent, or something goes wrong before that.

[Seme4eg]

Sir, it was on my side totally. I am using stow to manage my dotfiles. So i created the .pam-gnupg file in my dotfiles dir and forgot to run stow . to create a symlink in home.. My bad. Things work now, thank you!

[cruegge]

To anyone else participating in this thread: I know the issue is pretty old, but if you're still interested, could you attempt the steps I described above for producing an agent log?

[kronikpillow]

Hi ... I just noticed this comment, sorry I completely forgot about this thread, and i stopped using pam-gnupg ever since the issue arrisen, I was never able to fix it ... but now, I'm tempted to try ... wi'll get back to you soon