On Sat 2025-02-08 21:45:52 +0100, Matěj Cepl via Gnupg-users wrote: > Wait? Why do you need to run pinentry from flatpak app? Isn’t it > run on the host system?
I think that's the point. pinentry is run from the host system, but the
invocation of gpg (which talks to gpg-agent, which in turn invokes
pinentry) happens within the flatpak environment.
Since gpg passes the environment as a string (well, several strings) to
gpg-agent, which uses that to set up the environment in which to invoke
pinentry, pinentry ends up with the flatpak environment.
I see the proposed patch at T7522, to make yet another configuration
variable which one of the hops along the chain would use to filter out
specific environment variables, leaving the user to figure it out for
themselves. I'm pretty sure most desktop users have no idea what the
"right" DBus session address is in any given context (even less than
they knew what $DISPLAY was supposed to be under X11), so it looks to me
like the whole process here is just giving the user enough rope to hang
themselves with :(
Have you considered pointing flatpak at gpg-agent's --extra-socket,
which i think is more constrained than the standard gpg-agent socket?
Does that help?
What if, in a FreeDesktop environment, the overall policy was just:
- gpg-agent decides where to display the pinentry, *not* the gpg
invocation which talks to gpg-agent
- by default, gpg-agent should know how to display the pinentry in the
main running desktop session.
- if you want something fancier, you need to design and maintain it
yourself.
This overall would suggest that passing through *any* environment
variables originating from gpg all the way through the
gpg→gpg-agent→pinentry chain would be a mistake, and argues for the
allowlisting approach proposed by ikloecker in T7522.
The only issue here is if gpg-agent somehow gets launched before the
DBUS_SESSION_BUS_ADDRESS variable is initially set for the login; in
that case, any D-Bus-based pinentry would simply fail each time
gpg-agent tried to launch it. So we'd need to ensure that
DBUS_SESSION_BUS_ADDRESS is set correctly before launching gpg-agent.
This is made more confusing by the myriad pinentries, not all of which
care about DBUS or other environment variables anyway.
--dkg
PS I also note that this whole process is starting to smell like
something that lets a flatpak app smuggle a directive to something
outside the flatpak environment -- which, as i understand it, is
something that flatpak is supposed to limit. I don't know whether
anyone with a background in the flatpak security model has tried to
analyze this situation.
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
