Nixpkgs: kwallet complain about pinetry not installed when trying to open it

[pasqui23]

Describe the bug
When trying to open kwallet instead a dialouge pop up that complain about pinetry not installed
Of note that I have programs.gnupg.agent.enable=true

Expected behavior
kwallet open up as normal and give me the password

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Metadata

• system: "x86_64-linux"
• host os: Linux 5.2.21, NixOS, 20.03pre200231.7827d3f4497 (Markhor)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.4pre20191022_9cac895
• channels(root): "nur, nixos-20.03pre200231.7827d3f4497, home-manager"
• channels(paki): "nixos-20.03pre196201.07d4df59626"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
  -programs.gnupg.agent
  -services.xserver.plasma5

[juselius]

I can confirm this. gpg-agent gives the following in the logs:

gpg-agent[2733]: can't connect to the PIN entry module '/nix/store/pc0nsqh7nfvh82faz0hd574xz014rf2d-gnupg-2.2.17/bin/pinentry': IPC connect call failed

The pinentry program is missing from the gnupg package.

[pasqui23]

Weirdly it seem resolved in the latest update

• system: "x86_64-linux"
• host os: Linux 5.2.21, NixOS, 20.03pre201996.41d921292e9 (Markhor)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.1
• channels(root): "nixos-20.03pre201996.41d921292e9, nur, home-manager"
• channels(paki): "nixos-20.03pre196201.07d4df59626"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

[juselius]

We need to reopen this. It's not working on my side. I use gpg-agent for ssh, password-manager, etc., etc. and nothing works currently (using home-manager and 20.03pre201996.41d921292e9).

[juselius]

I believe I have found the cause: pinentry is only enabled if guiSupport is enabled in pkgs/tools/security/gnupg/20.nix, but all-packages.nix looks like this:

  gnupg20 = callPackage ../tools/security/gnupg/20.nix {
    guiSupport = stdenv.isDarwin;
    pinentry = if stdenv.isDarwin then pinentry_mac else pinentry-gtk2;
  };
  gnupg22 = callPackage ../tools/security/gnupg/22.nix {
    guiSupport = stdenv.isDarwin;
    pinentry = if stdenv.isDarwin then pinentry_mac else pinentry-gtk2;
  };
  gnupg = gnupg22;

I’ll create an overly and test later.

[juselius]

The problem can be "fixed" by setting

services.gpg-agent.extraConfig = "pinentry-program ${pkgs.pinentry-gtk2}/bin/pinentry";

in home-manager.

[ghost]

@juselius this didn't work for me. I still receive gpg: decryption failed: No secret key

Here's my declaration in home.nix:

    gpg-agent = { 
      enable = true; 
      defaultCacheTtl = 60480000; 
      defaultCacheTtlSsh = 60480000; 
      maxCacheTtl = 60480000; 
      maxCacheTtlSsh = 60480000; 
      enableSshSupport = true; 
      extraConfig = ''
        pinentry-program ${pkgs.pinentry-gtk2}/bin/pinentry;
        allow-emacs-pinentry
        allow-loopback-pinentry 
        ''; 
      }; 

[juselius]

Did you stop gpg-agent?

systemctl —user stop gpg-agent

[dpaetzel]

Thanks for working on this! @juselius’s suggestion alone did not work for me either, even after stopping gpg-agent.

However, inspired by this, I executed

gpgconf --reload gpg-agent
gpg-connect-agent /bye

… and it worked again (I cannot quite reproduce which command did it exactly though).

In my configuration.nix:

programs.gnupg.agent.enable = true;
programs.gnupg.package = (pkgs.gnupg.override { guiSupport = true; });

In my home.nix:

services.gpg-agent = {
  enable = true;
  extraConfig = "pinentry-program ${pkgs.pinentry-gtk2}/bin/pinentry";
};

EDIT: I'm not sure at all which parts of this configuration are actually necessary—I was experimenting wildly to finally get passwords out of my password-store again.

[dpaetzel]

OK, it seems that having

programs.gnupg.agent.enable = true;

in configuration.nix and

services.gpg-agent = {                                                
  enable = true;                                                                                                 
  extraConfig = "pinentry-program ${pkgs.pinentry-gtk2}/bin/pinentry";
};

in home.nix and then running

gpgconf --reload gpg-agent 

does the trick.

[juselius]

I don't have any gpg configs in configuration.nix, only in home.nix. It's probably the gpgconf reload which does the trick, although I cannot confirm it since my config worked after restarting.

[juselius]

Commit 3d832dee disables gui and pinentry by default to solve a dependency cycle. The problem is that this also breaks gpg-agent in the process. We need a different solution, since breaking gpg-agent in order to solve a technical problem is not really viable in the long run. Any comments @flokli and @fpletz?

[ghost]

The fix from @dpaetzel fixed it!

Committers: please be careful when screwing with gpg-agent in the future. I use it for real work and from this thread I'm not the only one.

[flokli]

@dpaetzel, @Spass1966 the changes from https://github.com/NixOS/nixpkgs/pull/71095 should cause the systemd user gpg-agent.service unit to be configured with an appropriate --pinentry-program parameter - can you please check your systemctl --user cat gpg-agent.service output?

gpg-agent.socket should auto-activate that gpg agent, as soon as gpg looks for an agent, so it shouldn't start its own.

On top of that, @jtojnar proposed shipping a somewhat smarter wrapper than just a dumb pinentry-curses in https://github.com/NixOS/nixpkgs/issues/72597#issuecomment-549274360, which will also honor pinentry from $PATH.

On top of fixing the situation from people not having enabled programs.gnupg.agent.enable, it should also improve the situation on non-NixOS, too, because it'll execute whatever pinentry is configured there.

[juselius]

Glad this got fixed quickly. Good work guys!

[dpaetzel]

can you please check your systemctl --user cat gpg-agent.service output?

Indeed, there is

ExecStart=/nix/store/…gnupg-2.2.17/bin/gpg-agent --supervised --pinentry-program /nix/store/…pinentry-1.1.0-gnome3/bin/pinentry

Based on that, it should have _just worked_™? But it didn't! What did I do wrong? I might have had gnupg installed via environment.systemPackages and not enabled programs.gnupg.agent.enable but I'm not sure about that anymore.

[dpaetzel]

Actually, I just removed the pinentry-program line from home.nix, did home-manager switch, checked that that line was actually gone in gpg-agent.conf, rebooted (just to be sure) and it still works like a charm!

[jtojnar]

programs.gnupg.agent.enable = true; should be sufficient when not using home-manager.

If you enable the service using home-manager, you will need to configure it there, as it apparently replaces the service definition.

[dpaetzel]

Ah, I see. That makes sense and is exactly what I experience. Thank you for the clarification! :slightly_smiling_face:

[pasqui23]

Now kwallet start normally,but ask for my password at startup even as I have the same passord for the wallet and my session

[andir]

tl;dr: machinectl shell [email protected] to get a shell with all the systemd user services working if you have a user that usually isn't interactive but you need to fiddle with GPG…

The pinentry no longer being found by GPG is also a problem for servers that use GPG where there isn't a systemd user session for each service that needs GPG... Sometimes you have to log into them and do stuff with the agent. Being forced to manually fiddle with the gpg-agent invocation or having to upgrade the user to a user with a systemd session is just wrong.

I haven't been a fan of the brekage at all. It breaks basically all of my GPG usage. It doesn't work for my workstation (that I sometime access via SSH) neither does it work for servers. It now requires more systemd craft... Great....

IMO we should revert to the state it had before.

[neumantm]

I also have this problem. I only have sddm and plasma5 enabled and not gnupg.agent. I don't use home manager. KDE Wallet always just worked until I upgraded to 20-03 today.

I don't care what options need to be set in the background. But I'd expect enabling plasma5 would automatically set them correctly, so that KdeWallet works out of the box.

EDIT: Just enabling gnupg.agent resolved it, but like I said I think KdeWallet should work out of the box. Especially as KDE is the desktop manager which is suggested to beginners in newly generated configuration.nixs.

[stale[bot]]

I marked this as stale due to inactivity. → More info