My proposed solution is to add a config variable pinentry-ignored-env to gpg-agent which specifies a comma-separated list of environment variables which should not be passed from the client to pinentry.

Patch:

https://lists.gnupg.org/pipermail/gnupg-devel/2025-February/035782.html

An alternate solution might be to make configurable the whole static list of environment variables that can be passed from client to agent, instead of hard-coding them. I avoided this approach since several of these variables already have custom logic associated with them, so it would require a more delicate change.

It's pretty ironic that we added DBUS_SESSION_BUS_ADDRESS because of pinentry-gnome3 and now we need to add an option to remove it because of pinentry-gnome3.

Given that we added DBUS_SESSION_BUS_ADDRESS for the special use case of someone manually launching a separate DBUS session (T3947) it seems more sensible to me to not pass DBUS_SESSION_BUS_ADDRESS unless explicitly configured with an option even if this causes a regression for those few who do use a separate DBUS session. Or is launching a separate DBUS session a common thing on Gnome?

it seems more sensible to me to not pass DBUS_SESSION_BUS_ADDRESS unless explicitly configured with an option

Yes, I'm happy either way. I think it just needs to be configurable one way or the other, because the problem in this case is caused by the environment variable being passed no matter what.

Or is launching a separate DBUS session a common thing on Gnome?

I can't speak for every use-case but systemd.io does say the following:

Single Graphical Session

systemd only supports running one graphical session per user at a time. While this might not have always been the case historically, having multiple sessions for one user running at the same time is problematic. The DBus session bus is shared between all the logins, and services that are started must be implicitly assigned to the user’s current graphical session.

• https://systemd.io/DESKTOP_ENVIRONMENTS/

What about deleting the environment variable in gpg-agent:

gpg-connect-agent 'OPTION putenv=DBUS_SESSION_BUS_ADDRESS' /bye

or to use a pinentry-wrapper?

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

I don't think that is a viable solution though, since every user of any Flatpak that packages gpg will run into this problem and the current behavior is only correct for the niche use-case where a user has multiple DBus sessions running for multiple display servers.

It would be preferable to have some way within the gpg-agent to either prevent the pass-through of this variable from the client or to default to not passing it through (imho).

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Here we go:

--change-std-env-name -name
        The  agent uses a fixed list of environment variables which are passed on to the Pinentry.  This option allows to remove variables from that list.  For example:

     change-std-env-name -DBUS_SESSION_BUS_ADDRESS