On 08/02/2025 17:51, jay.kayes--- via Gnupg-users wrote:
Hi all,
I've been debugging using gpg in flatpak apps. Particularly, I use
Evolution as a flatpak for email. The issue I am having is that gpg
private key operations only work if the card pin or key passphrase is
already in the agent cache. Pinentry does not work when triggered by a
gpg operation from a flatpak sandboxed app. I can only decrypt email
when I've done a gpg operation outside the sandbox to get the pin entered.
Hi Jay,
I was about to file the same issue in the bug tracker, except in my case
the flatpak in question is Thunderbird, which exhibits the same behavior
that you detailed. I also traced the issue to the same cause - that gpg
running in the flatpak is sending its DBUS_SESSION_BUS_ADDRESS to the
agent which then passes it to pinentry.
I have a proposed patch which I am preparing to send which adds a
gpg-agent configuration parameter to specify which environment variables
sent by the client should be *ignored* by the agent. This solves the
problem in my case, by filtering out DBUS_SESSION_BUS_ADDRESS ensuring
that the agent's environment is used by pinentry (for that specific
env-var).
In the meantime, the workaround I have been using is to configure
gpg-agent to use a custom pinentry command (~/.gnupg/gpg-agent.conf):
pinentry-program /home/sam/bin/pinentry-wrap
which then sets the correct environment for pinentry (pinentry-wrap):
#!/bin/bash
PINENTRY="/usr/bin/pinentry-gnome3"
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1001/bus"
${PINENTRY} "$@"
> I haven't thought about this further, but could a malicious program
> compromise the agent somehow by setting some unexpected values?
AFAIK the agent only accepts a specific list of environment variables
from the client which can be listed using:
$ gpg-connect-agent 'getinfo std_env_names' /bye
Best Regards,
Sam
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
