Describe the bug

gpg-agent stopped working recently. The systemd user service that is supposed to exist if programs.gnupg.agent.enable = true; fails to start. This does not seem to be relavant for most gpg actions, since it will autostart the agent if needed (albeit possibly missing the pinentry program configuration?), but it breaks usage of gpg-agent as ssh-agent.

Steps To Reproduce

Steps to reproduce the behavior:

1. activate gpg-agent with ssh support, e.g. with this snippet in the system configuration:

  programs = {
    ssh.startAgent = false;
    gnupg.agent = {
      enable = true;
      enableSSHSupport = true;
    };
  };

3. build and switch to new system configuration
4. inspect the systemd user service

systemctl status --user gpg-agent
× gpg-agent.service - GnuPG cryptographic agent and passphrase cache
     Loaded: loaded (/etc/systemd/user/gpg-agent.service; linked-runtime; preset: enabled)
    Drop-In: /nix/store/0ha5ynjimnl1fv83zs7npshcsskjhq8l-user-units/gpg-agent.service.d
             └─overrides.conf
     Active: failed (Result: exit-code) since Tue 2023-01-31 15:12:45 CET; 15min ago
   Duration: 1ms
TriggeredBy: ● gpg-agent.socket
             ● gpg-agent-ssh.socket
       Docs: man:gpg-agent(1)
    Process: 354707 ExecStart=/nix/store/2ixfs8a6jb6i9c89maniy4ilhw9mszcz-gnupg-2.3.7/bin/gpg-agent --supervised --pinentry-program /nix/store/36a1j2mws4di1c766lcxlf3rjpbsk8j5-pinentry-1.2.0-gtk2/bin/pinentry (code=exited, status=2)
   Main PID: 354707 (code=exited, status=2)
        CPU: 1ms

Jan 31 15:12:45 devpool039 systemd[1587]: Started GnuPG cryptographic agent and passphrase cache.
Jan 31 15:12:45 devpool039 systemd[1587]: gpg-agent.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jan 31 15:12:45 devpool039 gpg-agent[354707]: gpg-agent[354707]: WARNING: "--supervised" is a deprecated option
Jan 31 15:12:45 devpool039 gpg-agent[354707]: gpg-agent (GnuPG) 2.3.7 starting in supervised mode.
Jan 31 15:12:45 devpool039 gpg-agent[354707]: no LISTEN_PID environment variable found in --supervised mode (ignoring)
Jan 31 15:12:45 devpool039 gpg-agent[354707]: no LISTEN_FDS or LISTEN_FDNAMES environment variables found in --supervised mode (assuming 1 active descriptor)
Jan 31 15:12:45 devpool039 gpg-agent[354707]: Fatal: file descriptor 3 must be valid in --supervised mode if LISTEN_FDNAMES is not set
Jan 31 15:12:45 devpool039 systemd[1587]: gpg-agent.service: Failed with result 'exit-code'.

4. try listing ssh keys

ssh-add -l
Error connecting to agent: No such file or directory

Expected behavior

gpg-agent systemd user service starts sucessfully. SSH can use it as an ssh-agent.

Additional context

The missing gpg-agent does not seem to be relevant for performing gpg tasks, since it get's autostarted by gpg when needed. But for using it as an ssh-agent this does not happen.

Upstream has removed the example systemd user units in https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed , the related ticket https://dev.gnupg.org/T6336 gives some background information:

Actually, the entire systemd based launching is deprecated and thus the logged warning is on purpose.

The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

I'm not sure if this applies here at all. My interpretation is that abovementioned race condition is relevant if the systemd user unit is socket activated. If it is started on login gpg should detect the already running agent reliably and not start another one, so that should be fine.

I read https://github.com/NixOS/nixpkgs/blob/1c02dbee4726f9cde21cd103cc1e56dd2b20d72e/nixos/modules/programs/gnupg.nix#L47#L50 as "with ssh support the service is started on login, without it it's socket activated", but I did not find the corresponding implementation. I guess it's actually still socket-activated, but since https://github.com/NixOS/nixpkgs/blob/1c02dbee4726f9cde21cd103cc1e56dd2b20d72e/nixos/modules/programs/gnupg.nix#L141#L145 configures environment.extraInit causing gpg to be used very early in a session and the agent is then setup.

I don't know what the correct solution is, since upstream discourages using the systemd user units and I just want my gpg as ssh-agent back.

Notify maintainers

@fpletz @vrthra @mrcjkb @rnhmjoj @SuperSandro2000 @pennae

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.90, NixOS, 22.11 (Raccoon), 22.11.20230130.f413457`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.1`
 - nixpkgs: `/nix/store/5hf3g9wlhv2y6fbzxfrmrkics88g0pv0-source`