Can't get gnupg to work: no pinentry

Hi there,

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

#programs.gnupg.agent = {
#enable = true;
#pinentryFlavor = "gnome3";
#enableSSHSupport = true;
#};

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’m stuck, if anyone has an idea :slight_smile:

2 Likes

I also struggled to get this working on my nixOS setup!

I had to enable the pcscd service.

The snippets from my configuration.nix are:

services.pcscd.enable = true;
programs.gnupg.agent = {
   enable = true;
   pinentryFlavor = "curses";
   enableSSHSupport = true;
};

I also have the pinentry-curses added to systemPackages.

1 Like

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

3 Likes

I had some trouble with gnome pinentry that I fixed by setting:

services.dbus.packages = [ pkgs.gcr ];

Perhaps could be useful for you too

2 Likes

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…

Have you been making sure to restart gpg-agent (pkill gpg-agent) between each configuration change?

1 Like

Yes I did, I used kill and reload the config, also trying independently, even tried reboot on the most “usual” combination I was trying

Shucks!
Let’s dig deeper.

I just remembered I had to modify my gpg-agent.conf configuration in ~/.gnupg.
Here is the contents of that file:

 $  cat ~/.gnupg/gpg-agent.conf

    debug-pinentry
    debug ipc
    verbose
    enable-ssh-support
    # disable-scdaemon
    pinentry-program /run/current-system/sw/bin/pinentry

gpgconf came in handy for debugging configuration changes.
I ran gpgconf --reload gpg-agent throughout after making changes.

I also highly recommend reading some of the GnuPG developer’s troubleshooting advice in tickets like this one.

2 Likes

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)
systemctl --user restart gpg-agent
1 Like

Thx everybody!

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 :slight_smile: )

1 Like

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…

Similarly to what was mentioned above, I’m using this config for quite a long time without any problems.


  # GnuPG
  programs.gnupg.agent = {
    enable = true;
    enableSSHSupport = true;
  };
  services.pcscd.enable = true;

The only thing that I had to do to solve the “no pinentry” problem was:

$ cat ~/.gnupg/gpg-agent.conf
pinentry-program /run/current-system/sw/bin/pinentry

and of course adding the pinentry in the list of packages.

Forgot to say that gpg decryption required that the agent is enabled:

programs.gnupg.agent.enable = true;

1 Like

Can you now successfully run gpg --homedir . --quick-gen-key hovno in any directory, other than home?

Actually no - it says “no pinentry”.

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

For me, there is no additional --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:

Drop-In: /nix/store/1k8wmv9drcc3bzr11pai099xid932wdz-user-units/gpg-agent.service.d
         └─overrides.conf

Oops, I’m missing that… thanks.

Anyway, the running agent ps -aux | grep gpg still not executing the command with --pinentry. So, something around this might be wrong.

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.

8 Likes

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:

  services.gnome.gnome-online-accounts.enable = lib.mkForce false;
  services.gnome.gnome-keyring.enable = lib.mkForce false;
  programs.seahorse.enable = lib.mkForce false;

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.