Thanks for all the comments guys. I’ve opened a bug report in GnuPG’s bug tracker:
https://dev.gnupg.org/T4744
I think I’ve managed to track the issue down to a certain dbus issue I have applied a workaround for a while ago. Unfortunately, disabling that workaround fixes GnuPG’s behaviour but it breaks other applications more severely. I’ll explain:
Back when I’ve initially configured my system, I wanted to use startx as a desktop manager and Awesome as WM. I didn’t want to enable Awesome from my configuration.nix because I wanted to feel the “user freedom” of applying (e.g) overlays to my awesome packages without having to change root owned files.
Then I noticed, that a certain program I spawn in the background of my X sessions - mpd-mpris, doesn’t work as expected: (1) When it’s running I don’t see an mpd player with playerctl -l and (2) when ever I try to rerun it, I see a new dbus-daemon process in htop every time I spawn mpd-mpris.
While investigating that, I noticed that NixOS’ startx doesn’t run these commands:
if test -z "$DBUS_SESSION_BUS_ADDRESS"; then
eval $(dbus-launch --exit-with-session --sh-syntax)
fi
systemctl --user import-environment DISPLAY XAUTHORITY
if command -v dbus-update-activation-environment >/dev/null 2>&1; then
dbus-update-activation-environment --all --systemd --verbose
fi
While other desktop managers do run these commands as part of their wrapping of xinit or whatever. Evidence:
https://github.com/NixOS/nixpkgs/blob/8302338ae99b81db102cceec8212b5c5dcce4e3f/nixos/modules/services/x11/display-managers/default.nix#L39-L53
I’ve also noticed these commands exist in Arch Linux somewhere in /etc/ by default and there, I’ve had no such problems as with mpd-mpris.
Hence, my workaround was including these dbus commands in my .xinitrc and this has thankfully solved mpd-mpris’ issue. Moreover, I’ve been proven my workaround is correct because according to my tests, with whatever window & desktop managers, $DBUS_SESSION_BUS_ADDRESS has a value in these tested X sessions of something like:
unix:abstract=/tmp/dbus-tFb5MypqHu,guid=a4834e61f0e7d3158e5610d75dc7be4c
Without adding these dbus commands to my .xinitrc, $DBUS_SESSION_BUS_ADDRESS is empty and this explains why e.g mpd-mpris doesn’t know how to connect to dbus and that’s why it spawns a new dbus-daemon every time it tries to run.
When I tried removing these lines from my .xinitrc, I’ve found that gpg asks for passwords also inside X sessions, just like outside of it.
Here are other details I’ve also mentioned in upstream’s bug report:
- My
pinentry-program is /home/doron/.bin/pinentry which is a script I wrote which has:
#!/bin/sh
# BASED ON https://unix.stackexchange.com/a/236747/135796
# choose pinentry depending on PINENTRY_USER_DATA
# requires pinentry-curses and pinentry-gtk2
# this *only works* with gpg 2
# see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802020
case $PINENTRY_USER_DATA in
"")
exec pinentry-tty "$@"
;;
curses|emacs|gnome3|gtk-2|qt|tty)
exec pinentry-${PINENTRY_USER_DATA} "$@"
;;
*)
echo there is no such pinentry program: pinentry-"${PINENTRY_USER_DATA}" >&2
exit 1
esac
How do you run the gpg-agent? Do have gpg launch it on demand
or are you using socket activation?
- With either
gpg-agent.socket enabled as a systemd user service (when the package gnupg is installed to my user environment) or when I enable the relevant programs.gnupg options, I can always see 1 gpg-agent process in htop.
- Even if I disable the systemd unit
gpg-agent.socket, I see a gpg-agent process spawned whenever I run a gpg command.
- There is never more then 1
gpg-agent process running, gpg doesn’t allow that.
Perhaps the most interesting detail to mention (also mentioned in upstream’s bug report) is:
- In systemd’s journal, I can see this log line when I try to reload the agent:
gpg-agent[12823]: Failed to lookup password for key n/A85E4FC6C29CD42DB9DACBB14871FBABAAC9BC95 with secret service: Cannot autolaunch D-Bus without X11 $DISPLAY
What makes the issue a valid upstream’s bug IMO is the fact that for whatever reason the agent doesn’t know how to lookup the password, it allows the decryption without password no matter what.
BTW I’ve also tried running manually gpg-agent (while the systemd service & socket are stopped & disabled) like this:
env -u XAUTHORITY -u DBUS_SESSION_BUS_ADDRESS -u DISPLAY gpg-agent --daemon
But no luck, the password is still never prompted.