Multiple GPG Agent lead to broken signing

[Stoppedpuma]

Not sure which profile causes this as setting gpg* to complain doesn't fix this. I encountered this with lazygit and was unable to commit until a teardown. Logs don't show anything, just this from journalctl:

gpg-agent[58120]: command 'PKSIGN' failed: No pinentry
gpg-agent[58120]: failed to read the secret key
gpg-agent[58120]: failed to unprotect the secret key: No pinentry
gpg-agent[58120]: can't connect to the PIN entry module '/usr/bin/pinentry': End of file
gpg-agent[58120]: SIGHUP received - re-reading configuration and flushing cache

[roddhjav]

That is a tricky one.

To sum up the issue,

• Upon need, GPG start a new gpg-agent daemon to handle keyring for each keyring (~/.gnupg, /etc/apt/trusted.gpg.d/, /etc/pacman.d/gnupg/, any other user keyring you have).
• The default gpg-agent has access to most keyrings (ideally it should be limited to only the user's one (so ~/.gnupg). So the first time you use gpg, it should be ok.
• Other agent can be started with different keyring under a different profile (eg: pacman//gpg)
• Sometime a program (in this example, lazygit) can use a gpg-agent that run under a profile that prevent access to the actual needed keyring.
• It is a pain to debug

I currently don't know how to fix this in a correct way.

[roddhjav]

This should now be fixed.

[Stoppedpuma]

Still seems to fail, GPG gives this output:

error: gpg failed to sign the data:
[GNUPG:] KEY_CONSIDERED (hidden)
[GNUPG:] BEGIN_SIGNING (hidden)
gpg: signing failed: No pinentry
[GNUPG:] FAILURE sign (hidden)
gpg: signing failed: No pinentry

fatal: failed to write commit object

[roddhjav]

You may need to kill any gpg-agent and scdaemon and try it again.

Meanwhile, do you gave any logs?

[Stoppedpuma]

This issue still persists after a reboot, aa-log doesn't seem to have logs for either gpg or scdaemon.

[roddhjav]

Does it have any other logs than gpg?

[Stoppedpuma]

Not necessarily, just from typical unrelated programs such as mpv, yt-dlp, waybar, that sort of thing. I'm not entirely sure which profile is causing this either as setting both gpg* and scdaemon to complain doesn't seem to solve this issue but a teardown does.

[roddhjav]

Please, share these logs anyway.

[Stoppedpuma]

I managed to get logs with gpg in them, no idea why I wasn't getting them prior? These can be downloaded here.

[roddhjav]

They is no gpg in these logs...

Can you provide the output of ps auxZ | grep gpg & ps auxZ | grep scdaemon to see how your gpg-agent are confined?

Also, you need to configure @{XDG_PROJECTS_DIR} to match your (hidden) directory.

[Stoppedpuma]

They is no gpg in these logs...

I seem to have misread git as gpg, my apologies!

Can you provide the output of ps auxZ | grep gpg & ps auxZ | grep scdaemon to see how your gpg-agent are confined?

Also, you need to configure @{XDG_PROJECTS_DIR} to match your (hidden) directory.

This is already set to that directory.

[roddhjav]

Your ps means that apparmor is currently disabled...
What distribution/DE are you on?

This is already set to that directory.

Beware, it is a relative path from @{HOME}.

[Stoppedpuma]

Your ps means that apparmor is currently disabled...

Not sure why, aa-status reports correctly and logs are being filled.

What distribution/DE are you on?

Arch Linux, sway (This is reproducible under Hyprland as well if that matters)

[roddhjav]

Not sure why, aa-status reports correctly and logs are being filled.

Hum, can you try with sudo in front of the ps?

[Stoppedpuma]

user 1922471 0.0 0.0 7924 5088 pts/5 S+ 22:40 0:00 rg gpg
user 1942674 0.0 0.0 7928 5248 pts/5 S+ 22:40 0:00 rg scdaemon

[roddhjav]

Hum... with ps auxZ as I asked before... I have the feeling you don't want me to help you...

Also, when you run this, please ensure you do have a gpg agent started, and that it does lead to broken signing.

[Stoppedpuma]

Hum... with ps auxZ as I asked before... I have the feeling you don't want me to help you...

I don't know where you got this from, if I didn't want help / a fix I wouldn't have opened the issue. That was the output from running with sudo.

Also, when you run this, please ensure you do have a gpg agent started, and that it does lead to broken signing.

This would probably be why there wasn't anything else as I rebooted sometime between and must've forgot retrying the commit again, retrying after doing that does have more this time.

sudo auxZ | grep scdaemon
user 6338 0.0 0.0 83240 5108 ? SLl 15:37 0:00 scdaemon --multi-server
user 6736 0.0 0.0 7704 5248 pts/1 S+ 15:37 0:00 rg scdaemon

sudo auxZ | grep gpg
user 6336 0.0 0.0 155796 4856 ? SLsl 15:37 0:00 /usr/bin/gpg-agent --supervised
user 6790 0.0 0.0 7700 5120 pts/1 S+ 15:37 0:00 rg gpg