I can’t get Gnupg to work no matter what I try. I’ve read the different topics and github issues and tried the different work-around but I’m still getting the same error when trying to generate keys : no pinentry.
In my pkgs in configuration.nix I added pinentry and pinentry-gnome, and gnupg. I tried all the different flavors of pinentry like pinentry_gnome and same thing with gnupg.
I tried them alone or together, every combination.
I also added or disabled the user agent with
In the same manner, I tried this configuration alone or in combination of the pkgs.
I reloaded gnupgconf, stopped and restarted the agent, nothing works.
I have no gpg-agent.conf file somehow
Using a GUI will give the same (absence of )result
running the agent in debug mode will give this result
gpg-agent[14939]: starting a new PIN Entry
gpg-agent[14939]: can't connect to the PIN entry module '/nix/store/f9kky9505yj9sbvg2i643ikw3nw9p092-gnupg-2.2.27/bin/pinentry': IPC connect call failed
gpg-agent[14939]: DBG: error calling pinentry: No pinentry <GPG Agent>
gpg-agent[14939]: command 'GENKEY' failed: No pinentry
gpg-agent[14939]: DBG: chan_9 -> ERR 67108949 No pinentry <GPG Agent>
I use pinentryFlavor = "gtk2"; because I’ve found that all the other flavors have at least one context where they just don’t work. But gtk2 has never failed me, even when I’m only logged in remotely over SSH
Thank you for you replies @ElvishJerricco and @efx , that didn’t do it unfortunately.
I have had Nixos running for 2 weeks and this is the first dead end I’m running into. In my field it’s a big one, I cannot communicate with some of my sources without pgp.
I get that there could be some path issue but this system is too new for me to understand at the moment.
I will try that right now @Misterio
EDIT : nop, didn’t do the trick…
I also remember I used @rnhmjoj’s splendid troubleshooting advice found in this closed NixOS issue.
Specifically using systemctl to see the logs from gpg-agent and restart it.
see the logs
systemctl --user status gpg-agent
restart it (this is probably better than my gpgconf --reload advice above)
It works. I switched back to Guix while I needed gpg because I knew it worked over there and I knew how to install it quickly (I needed to be sure I would not take too long to get to work.)
When I reinstalled Nixos gnupg just worked with my config, so I assume it was a user error, I may have only reloaded gpg-agent and not restart it (as I was aware that I may have to do it, thx @efx for the reminder as it took me some time to find this information)
EDIT: I used the same configuration.nix file
While we are at it, what is the difference between a rebuild, a reboot and a reinstallation? Shouldn’t that be the same things? And between reloading a service and rebooting. Shouldn’t a reload be sufficient? Why not?
When I rebuild Nixos, it tells me which services are reloaded and which are not. If I carefully check those indication and eventually manually reload the one that weren’t, should I reboot? If so, how do I know a reboot may be needed?
Thank you very much for your patience and efforts )
Thanks for this tip. I just tried half an hour to get gnome3 or other settings (including the gcr workaround provided below) to work. gtk2 is the only one that works in a terminal, and in a Wayland session…
I’m also experienced this. Currently, I discover a problem that might be the cause.
After setting programs.gnupg.agent.pinentryFlavor, gpg-agent service doesn’t get overridden as intended in this lines. It is still strange however, because pinentry-program configuration doesn’t change the behavior of the agent/daemon.
May be someone can verify to look at the service getting run.
$ systemctl --user status gpg-agent
○ gpg-agent.service - GnuPG cryptographic agent and passphrase cache
Loaded: loaded (/etc/systemd/user/gpg-agent.service; linked-runtime; vendor preset: enabled)
^-- get this
$ cat /etc/systemd/user/gpg-agent.service
ExecStart=/nix/store/jf1j104ampdwdhi56nvwr18101s5zvi9-gnupg-2.2.27/bin/gpg-agent --supervised
^-- no pinentry option
The NixOS module will not edit existing unit files, it uses drop-ins. systemctl status should show something like the following to point you to the correct location:
I’ve commented this a number of places, and I don’t know if there’s a better solution, but I’ve written some scripts based on this assumption and have never experienced pinentry issues ever again after years of dealing with them.
If you stop the service, and then run gpg, it will happily start up gpg-agent ITSELF. Aka, not the systemd unit, and thus not with the pinentry override.
Just make sure you do the equivalent of pkill -f gpg-agent; pkill -f pinentry and then systemctl --user restart gpg-agent{.socket,-extra.socket,-ssh.socket}.
I never have problems with pinentry since doing this.
I switched to Gnome this year and instantly began having gpg-agent problems despite all my knowledge of the other problems I’d had with it otherwise. I found that Gnome basically sabotages programs.gnupg.agent.enable unless I added these:
because otherwise they would bring in Gnome’s default gpg-agent stuff, which didn’t use the pinentry I’d configured with programs.gnupg.agent.pinentryFlavor
EDIT: I should mention I came up with those three lines by spelunking logs and process trees, and eliminated them one at a time. It’s possible only one or two of them is needed, but I haven’t tested because I don’t care about any of them.