weird behavior on Artix-suite66

kronikpillow commented 2 years ago

so, ever since i moved from Arch to Artix, i'v been having trouble signing my git commits with gpg until I run mw -Y (mutt wizard sync) which seems to fix the issue after running it, it's as if my gpg keys are not unlocked upon login, but are unlocked as soon as i run mw -Y to sync my mutt with my gmail, I am using pam-gnupg to unlock my gpg keys on login, apart from that i am also using gnome-keyring, but removing it from pam doesn't make any difference to the issue ...

here is my /etc/pam.d/login

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
auth       optional     pam_gnome_keyring.so
account    include      system-local-login
session    include      system-local-login
session    optional     pam_gnome_keyring.so auto_start
password   include      system-local-login

here is my /etc/pam.d/system-local-login

auth      include   system-login
account   include   system-login
password  include   system-login
session   include   system-login
auth     optional  pam_gnupg.so store-only
session  optional  pam_gnupg.so

here is my /etc/pam.d/passwd

#password   required    pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
#password   required    pam_unix.so sha512 shadow use_authtok
password    required    pam_unix.so sha512 shadow nullok
password    optional    pam_gnome_keyring.so

here is my ~/.gnupg/gpg-agent.conf

pinentry-program /usr/bin/pinentry-gnome3
allow-preset-passphrase
max-cache-ttl 86400

here is my ~/.gitconfig

[user]
    email = [email retracted]
    name = Dejan Kutle
    signingkey = 0AF6757E3DEA0025
[credential]
    helper = /usr/lib/git-core/git-credential-libsecret
[hub]
    protocol = ssh
[commit]
    gpgsign = true

in my ~/.config/pam-gnupg I have used the keygrip of the subkey with the [E] flag after using gpg -K --with-keygrip to get the keygrip

this is my xinitrc

#!/bin/sh
if [ -f "${XDG_CONFIG_HOME:-$HOME/.config}/x11/xprofile" ]; then
    . "${XDG_CONFIG_HOME:-$HOME/.config}/x11/xprofile"
else
    . "$HOME/.xprofile"
fi

ssh-agent dwm

this is my xprofile

#!/bin/sh
xrdb ${XDG_CONFIG_HOME:-$HOME/.config}/x11/xresources  # Uncomment to use Xresources colors/settings on startup
eval $(gnome-keyring-daemon --start)
polkit-gnome &      # start a policy kit agent
setbg &         # set the background with the `setbg` script
remaps &        # run the remaps script, switching caps/esc and more; check it for more info
xcompmgr &      # xcompmgr for transparency
dunst &         # dunst for notifications
unclutter &     # Remove mouse when idle

after i reboot and login, if i try to do a commit i get a

g commit -am "test"
error: gpg failed to sign the data
fatal: failed to write commit object

but as soon as i run mutt wizard sync (luke smith's mutt wizard) with the mw -Y command email syncs, and after that, I can make commits with git and they get signed with no issue ... I am confused as to why this is happening, this exact same setup on Arch works perfectly without the above issues

going further in to the issue

I''v tried removing

[credential]
    helper = /usr/lib/git-core/git-credential-libsecret
[hub]
    protocol = ssh

from .gitconfig .. it did not solve the issue

I'v tried

gpg --list-keys --fingerprint [my email]
gpg --sign --armor --default-key [my_fingerprint] <<EOT
Some message...
EOT

gpg hangs and nothing happens

further investigating and going back to ~/.gnupg/gpg-agent.conf i'v removed pinentry-program /usr/bin/pinentry-gnome3 upon login and attempting to sign a commit, i get a GTK pinentry prompt to input my password, hence for some reason, upon login the key is not unlocked, yet on the other side, as soon as I run mutt wizard with mw -Y to sync my email, the keys get unlocked ...

loging out, reloging again, and running GIT_TRACE=1 g commit -m "test" gives me the following output

GIT_TRACE=1 g commit -m "test"
19:43:31.288980 git.c:455               trace: built-in: git commit -m test
19:43:31.290233 run-command.c:666       trace: run_command: gpg --status-fd=2 -bsau 0AF6757E3DEA0025

and then it launches the GTK pinentry prompt, after I cancel entering the password i get a

error: gpg failed to sign the data
fatal: failed to write commit objec

hence, the end conclusion is that pam-gnupg for some reason does not unlock my key on login, but does unlock it as soon as i prompt mutt wizard, and then all other gnupg / gpg-agent related operations continue as normal, but having to sync my mail upon login just to unlock my key, sounds like a tedious task :D

following further on that stackoverflow post, changing the gpg program from gpg to gpg2, and backwards, does not solve the issue while runnining echo "test" | gpg --clearsign opens the GTK pinentry prompt, and succesfully signs the message ... after running echo "test | gpg -clearsign running git log --show-signature -1 as suggested in the stackoverflow post, gives me a

[commit 81aeb6571eac59851493bf0fee5846639b54b07c (HEAD -> master)
gpg: Signature made Sat 09 Oct 2021 12:55:41 PM CEST
gpg:                using RSA key E97D4DF9B44DF03C5B6689FD8CCA9FC7BC1BBF96
gpg: Can't check signature: No public key
Author: KronikPillow <kronikpillow@xxxxxxxx>
Date:   Sat Oct 9 12:55:41 2021 +0200

    test

output of echo $GPG_TTY tty is

tty
/dev/tty1
/dev/pts/1

any idea whats going on here? why does pam-gnupg not unlock my key on login? while it does unlock without a password prompt as soon as i sync my email with mutt wizard?

StarTroop commented 2 years ago

Seems like it's the same issue as I reported in #33. Passing mw -Y (which runs mbsync, and in turn, pass) triggers the password dialogue to unlock because it hadn't been unlocked at login. The author doesn't seem to be actively maintaining this anymore, and I'm not aware of any fix or alternatives, so a practical workaround could be to use systemd to activate pass shortly after login.

kronikpillow commented 2 years ago

except that i use suite66, not systemd :) well now i switched to runit, but same problem persists

aktersnurra commented 2 years ago

I get the same behavior on my system (artix/runit). Did you manage to solve it @kronikpillow?

cruegge commented 2 years ago

@aktersnurra Thanks for pinging, I've been ignoring this issue for too long.

@kronikpillow

i'v removed pinentry-program /usr/bin/pinentry-gnome3 upon login and attempting to sign a commit, i get a GTK pinentry prompt to input my password, hence for some reason, upon login the key is not unlocked, yet on the other side, as soon as I run mutt wizard with mw -Y to sync my email, the keys get unlocked ...

For clarification, does the key get unlocked on mw -Y even when not using pinentry-gnome3, or did you just check that the prompt appears without the pinentry setting, but not what mw -Y does in that case?

The thing is, pam-gnupg only tries unlocking directly on login. I assume that it simply fails for some reason, and the beaviour you observe is not directly related. Instead, gnome-keyring also has ways of storing your gpg password, and pinentry-gnome3 uses that if available. So what happens is probably:

pam-gnupg fails on login,
gpg tries to unlock the key and launches pinentry-gnome3, which fails / hangs for some other reason,
mw -Y fixes the pinentry issue in some way,
afterwards, gpg uses the password stored in gnome-keyring.

When you remove the pinentry setting, gpg instead uses default pinentry, which pops up the dialog you see. But after you cancel that, mw -Y should not fix the issue anymore if my guess is correct.

The only notable gpg-related line in muttwizard is export GPG_TTY=$(tty), so probably that's what's fixing it. Now, for popping up a graphical password prompt, the TTY should be irrelevant, but judging from the source of pinentry-gnome3, it falls back on a terminal-based pinentry in certain cases, so maybe something goes wrong there. E.g., is your DBUS_SESSION_BUS_ADDRESS set up correctly?

OTOH, we should maybe look into why pam-gnupg fails in the first place. Can you add the debug option to the pam_gnupg.so lines and check if your (journal | syslog | whatever Artix is using) shows any related output?

kronikpillow commented 1 year ago

I'v since moved away from Artix back to Arch, but still same issue .... on login, gpg-keys are not unlocked (this seems to be the case even without using pinentry-gnome3) i run mbsync (mutt-wizard's sync feature) and keys are automatically unlocked why does the key not get unlocked on login?

kronikpillow commented 1 year ago

added debug option to pam_gnupg.so lines ... result :


Oct 23 12:21:23 susanoo login[515]: pam_gnupg(login:auth): stored passphrase
Oct 23 12:21:23 susanoo kernel: audit: type=1100 audit(1666520483.455:113): pid=515 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring,pam_gnupg acct="kronikpillow" exe="/usr/bin/login" hostname=susanoo addr=? terminal=/dev/tty1 res=success'
Oct 23 12:21:23 susanoo audit[515]: CRED_ACQ pid=515 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring,pam_gnupg acct="kronikpillow" exe="/usr/bin/login" hostname=susanoo addr=? terminal=/dev/tty1 res=success'
Oct 23 12:21:23 susanoo login[515]: pam_gnupg(login:setcred): store-only set, skipping
Oct 23 12:21:23 susanoo kernel: audit: type=1103 audit(1666520483.459:115): pid=515 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring,pam_gnupg acct="kronikpillow" exe="/usr/bin/login" hostname=susanoo addr=? terminal=/dev/tty1 res=success'
Oct 23 12:21:23 susanoo login[515]: pam_gnupg(login:session): presetting passphrase succeeded, cleaning up
Oct 23 12:21:23 susanoo audit[515]: USER_START pid=515 uid=0 auid=1000 ses=1 msg='op=PAM:session_open grantors=pam_loginuid,pam_keyinit,pam_systemd_home,pam_limits,pam_unix,pam_permit,pam_mail,pam_systemd,pam_env,pam_gnome_keyring,pam_gnupg acct="kronikpillow" exe="/usr/bin/login" hostname=susanoo addr=? terminal=/dev/tty1 res=success'
Oct 23 12:21:23 susanoo audit[515]: CRED_REFR pid=515 uid=0 auid=1000 ses=1 msg='op=PAM:setcred grantors=pam_securetty,pam_shells,pam_faillock,pam_permit,pam_faillock,pam_gnome_keyring,pam_gnupg acct="kronikpillow" exe="/usr/bin/login" hostname=susanoo addr=? terminal=/dev/tty1 res=success'
Oct 23 12:21:23 susanoo login[515]: pam_gnupg(login:setcred): store-only set, skipping```

cruegge / pam-gnupg

weird behavior on Artix-suite66 #36